Buddhist: should it have an April new year before 1941?

[sffc]

We can keep the month codes the same. It's only the ordinal months that change.

[robertbastian]

• @hsivonen What would this mean for Java, etc?
• @sffc We're already deviating on Chinese, Hijri, etc. That ship has sailed
• @hsivonen Java doesn't do Chinese or Dangi. Of Hijri, it only ships Umm-al Qura, and to the extent dates stay within almanac, hopefully that part agrees. Java does Japanese only from 6 Meiji onward, so what's in the Java range matches Temporal. If you're going to touch Buddhist, that seems like a breaking change.
• @robertbastian Yeah, maybe let sleeping dogs lie
• @robertbastian Wikipedia actually calls this calendar Thai Solar, and there's a different lunar calendar that it calls Buddhist. If we get into this discussion we should also discuss the name, but I'd much prefer just saying this is the Buddhist calendar as implemented by systems like Java, JS, and ICU before us
• @sffc I agree that this probably isn't a problem worth solving on the existing Buddhist, and it's nice that we have a potential path to solving it by adding a new calendar with a new code.
• @robertbastian This is essentially a calendar change from a calendar using one era to one using another. We don't model the Julian/Gregorian change, because it's going to be messy. Implementing this would require a lot of special cases in code.
• @sffc I don't think this would be hard to implement. The month would count from M04 through M03, with the ordinal month mappings changing. This is easy to model. I think we should eventually support Gregorian switchovers, and Thai switchovers could be added at the same time.
• @robertbastian Do we want to document this as the "proleptic Thai solar buddhist calendar"? It's specifically not https://en.wikipedia.org/wiki/Buddhist_calendar
• @robertbastian - In 3.0 we should maybe rename a few calendars to be more accurate, Dangi is also a weird name
• @sffc Maybe
• @hsivonen Here is a link to Java docs. At least according to Java docs, their Thai Buddhist calendar is defined as a year shift proleptically: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/time/chrono/ThaiBuddhistChronology.html
• @sffc Let's form a conclusion with the CLDR group on Monday. It seems like we mostly agree.

[Manishearth]

I'm not sure this should be 2.1 blocking. Potentially stretch (we don't have a milestone, but i'm comfortable recording stretchiness in comments, or maybe even a label?)

[sffc]

We're still waiting on feedback from CLDR (@AEApple) on the impact of this behavior.

[robertbastian]

I agree this is not 2.1 blocking, the Buddhist calendar is not new, this behaviour has been there since pre 1.0.

[sffc]

Since I believe that calendars should align with the chronology of real groups of people, my prior is that we should use the April new years before 1941, but matching the ecosystem is a practical concern that carries a substantial amount of weight.

[Manishearth]

Whereas my position is that this is a clear "calendar change" felt by the users (unlike a change in lunar algorithm/observation sources), so by default we should be proleptic unless we are explicitly supporting a switchover calendar. Which we could, but the calendar should be defined as such.

[AEApple]

Filed an internal request 452317872 to have someone check the following questions for numeric dates:

• How are dates written in Thai newspapers when they talk about dates that happen pre-1941 since that is the year when the start of the year changed from April to January.
• Does that differ from how dates are written in modern history books for elementary students?
• How does the government on its websites write pre-1941 dates?
• What are the top regional websites/applications which are developed by Thai developers. How do they write dates?

Let me know if there are any other questions that would be helpful, although I wouldn't be surprised if we just can't find numeric date examples due to the ambiguity challenge.

[Manishearth]

Assessment for 2.1: Does not block milestone since it's mostly documentation. We currently do not strongly commit to any behavior in this crate.

Should be fixed by #7123 anyway.