Decide on default calendar sets (i.e. "what goes in AnyCalendar")

[Manishearth]

Previous discussion: #4889, #6227 (comment)

Current open issues/PRs related to this:

• Remove Hijri<AstronomicalSimulation> simulation code #7301
• Use an any-calendar without simulated Hijri in FFI #7314
• Avoid claiming that HijriSimulated corresponds to islamic-rgsa #7311
• Add Julian to AnyCalendar #7224

(please, please, add links to more if you remember them. IME these are really annoying to find when you need to)

Most recent ICU4X WG discussion: #7301 (comment)

We've been having a lot of discussions lately about AnyCalendar and what goes into it. I'm filing this issue to have a searchable place to discuss this, and consolidate discussion across these issues.

The history and status quo

Currently, AnyCalendar contains all ICU4X supported calendars except Julian, including HijriSimulated (Mecca) and JapaneseExtended.

This type was primarily designed to support FFI, browsers, and in general users wanting to write calendar-agnostic code. We wanted to focus on i18n-usable calendars, there was a discussion early on whether Julian should be a part of it and we decided it shouldn't. By "i18n-usable" I mean things that people would actually want to use on their systems, for e.g. date formatting.

JapaneseExtended was based on the initial CLDR era set, but discussions in Temporal and elsewhere showed that that era set isn't actually that usable. We initially planned on removing it, but we moved away from that decision (I no longer agree with my position there), and for 2.0 still had it in AnyCalendar.

Henri talks a bit about islamic-rgsa's history here. From ICU4X's side, we initially adopted it because ECMA and CLDR seemed to consider it a real calendar, but further investigation showed that while islamic-rgsa was intended to mean something when originally designed, it never really took off so as far as computer behavior is concerned it's basically meaningless. It took a while for Temporal to settle on this, but at this point we're in a state where we really should not be including this calendar with the others in AnyCalendar.

Policywise there is general consensus that the bar for including calendars in icu_calendar is low¹ (really, more of a maintainence question than anything else), and the actual careful bar is for AnyCalendar, but there's no clear consensus on what AnyCalendar should have.

Open questions

(All tied together and should be considered together)

• AnyCalendar is a stable type. What is its future? What is the bar for inclusion in AnyCalendar? What should we exclude from AnyCalendar?
• Should icu_calendar export multiple AnyCalendar-like types with different purposes? What should they be? What are the policies for inclusion there?
  • What happens to the AnyCalendarKind enum? Do we have multiple per-aggregate enums?
• Should icu_calendar export a way to cobble together your own AnyCalendar (Add make_any_calendar macro #7312)

Useful terminology for this discussion: We've been using GoodCalendar and AllCalendars to distinguish between AnyCalendar impls that are restricted to "good" calendars vs ones that contain every supported calendar. Whether or not AnyCalendar is one of these (or neither!) is a part of that discussion, but the names help.

Footnotes

1. Though now that Hijri and EastAsianTraditional are parametrized, we might want to revisit that policy for those calendars, as a part of stabilizing https://github.com/unicode-org/icu4x/issues/6962 ↩

[Manishearth]

My own preference is that GoodCalendar should contain i18n-useful, production-quality calendars, which corresponds to AnyCalendar minus japanext and rgsa. I am not strongly opposed to adding Julian to the mix, but I am generally opposed since it's not i18n-relevant.

It may be worthwhile to have an ECMACalendar that just matches what ECMA does, and is usable by Temporal/etc. At the moment, this is identical to what I have proposed for GoodCalendar, but it would diverge in the future as we add more calendars. We could add ECMACalendar when these calendars get added.

It may also be worthwhile to have an AllCalendar. I do not think we need to start with an AllCalendar; and instead can wait to see user needs for that before adding one. Currently, I see our largest user as ECMA implementors (temporal_rs, Gecko), and they do not need this.

Overall I prefer the route of taking the current AnyCalendar and shaping it into GoodCalendar by various deprecation strategies. I like #7301. I prefer this since I don't actually think our users care about japanext and rgsa and this serves them well, without further having a lot of API churn.

icu_calendar was graduated before we really understood some of these calendars and before we really had a strong understanding of our crate graduation needs. I'm not quite happy with us trying to piecemeal fix the API in 2.0, so if we can limit API churn I really prefer that.

[Manishearth]

cc @robertbastian @sffc

[sffc]

Thought: the distinction between GoodCalendar and AllCalendar is important for construction and certain methods, but not super important for storage. For example, AllCalendar could have try_from_prefs_good and try_from_prefs_all (names to be bikeshed), which both return an AllCalendar but link different data.

DateTimeFormatter already has its own internal calendar enum and uses the ConvertCalendar scaffold trait to push conversion logic to the caller / icu_calendar. I think since DateTimeFormatter works on enums, it would need a public GoodCalendar in order to avoid linking the conversion impls for the rest.

[Manishearth]

For example, AllCalendar could have try_from_prefs_good and try_from_prefs_all (names to be bikeshed), which both return an AllCalendar but link different data

Yep, though they would both link in calendar code for all calendars, and we've discovered that's nontrivial

[sffc]

For example, AllCalendar could have try_from_prefs_good and try_from_prefs_all (names to be bikeshed), which both return an AllCalendar but link different data

Yep, though they would both link in calendar code for all calendars, and we've discovered that's nontrivial

No? They only link in calendar code if a method is being called that links the calendar code, or if the enum is ever used as a dyn Calendar trait object (if that's even possible). If all the methods we call between construction and formatting are implemented for the good calendars (with some fallback/failure behavior for non-good calendars) then we don't need the extra public enum.

[Manishearth]

No? They only link in calendar code if a method is being called that links the calendar code

Most of the methods link in calendar code? I think we are talking about different things here, potentially.

I'm saying that if we had AnyCalendar::try_from_prefs_good() and AnyCalendar::try_from_prefs_all(), then while we wouldn't link in construction code, things that call e.g. .to_iso() or add() or anything that involves calendar math will link in that code for all calendars.

If all the methods we call between construction and formatting are implemented for the good calendars (with some fallback/failure behavior for non-good calendars) then we don't need the extra public enum.

I don't understand what your counterfactual is here. What extra public enum?

[sffc]

We can make sure icu_datetime doesn't use any of the all-calendar methods on AllCalendar. It can convert to its internal enum at the boundary. Then we can make AnyCalendar into AllCalendar and we don't need to export a GoodCalendar enum encoding value judgements about which calendars are good or not.

Temporal_rs can make its own enum, potentially using the helper macro in #7312

[Manishearth]

Oh, you are talking specifically about DateTimeFormat. Yes, we can avoid this problem narrowly for icu_datetime.

This doesn't address the problem for Gecko and temporal_rs, though. temporal_rs could make its own enum, but AllCalendar is not the best path forward for Gecko.

I think having an FFI-level GoodCalendar or ECMACalendar is useful for that, at least.

[sffc]

Maybe we should first discuss the plan for the ecma402 glue code. If it lives on its own crate that has its own FFI, like temporal_rs, then we can put GoodCalendar in there. I don't think icu_capi should export something materially different than icu_calendar

[Manishearth]

Maybe we should first discuss the plan for the ecma402 glue code. If it lives on its own crate that has its own FFI, like temporal_rs, then we can put GoodCalendar in there.

I do not want to make this discussion contingent on that. That is a discussion about future API for future client usage. This impacts current clients (temporal_rs and Gecko), and has to do with Temporal, not ecma402.

I don't think icu_capi should export something materially different than icu_calendar

I agree! This is why I would rather we solve this problem in icu_calendar's API (and have icu_capi copy it). I'm just noting that "clients can use the macro" is not always a solution given that we have non-Rust clients.

[sffc]

There's a solution for temporal_rs.

Where does Gecko come in? Are they doing something outside the scope of temporal_rs?

[Manishearth]

Gecko uses icu_capi, not temporal_capi. They implement Temporal using that.

(Also ecma402, which is why I wish to talk about this in terms of current API not a potential future ecma402 adapter crate)