icu4x
icu4x copied to clipboard
unicode-org
Expose Temporal CalendarDateYear / LDML extended year
It appears that Temporal CalendarDateYear / LDML extended year isn't exposed.
For Temporal compat, it should be exposed.
It could potentially be a new field on FormattableYear.
I'm waiting on https://github.com/tc39/proposal-intl-era-monthcode/pull/37 to land. If it does, I believe that ICU4X already exposes all of the information required for implementing Temporal.
Currently we do the correct thing except in the case of ethiopic (where we expose the same extended year as ethioaa) and roc (where we expose Gregorian).
intl-era-monthcode now defines an arithmetic year, we should just expose that.
cc @robertbastian Is the above^ the only thing that is remaining here? I know you were working on this and I don't want to shake things up if there already was a plan.
Also ethiopic. So they are both problems that will be fixed in the next release, it seems.
https://github.com/unicode-org/icu4x/commit/0753b061cfc83ebe5454a9c0c457fd9dea895f47
@sffc what do you think of releasing icu_calendar 2.0.3 with that patch and then declaring this issue fixed?
Looks like roc is already fixed upstream.
By upstream you mean main? Or did something change in temporal?
Sorry, I'm a little confused. What is your proposed change? I'm not aware of anything on the ICU4X main branch relating to calendars and YearInfo that isn't already on crates.io.
YearInfo exports all the information that Temporal_rs needs in order to implement the Temporal Year, but it does require a bit (not a lot) calendar-specific logic. ICU4X could maybe choose to export a temporal_year getter similar to the one we already have for the CLDR extended_year.
@sffc what do you think of releasing icu_calendar 2.0.3 with that patch and then declaring this issue fixed?
This PR doesn't impact Temporal Year. It impacts Extended Year which is no longer the same as Temporal Year.
@sffc Is it? For calendars with eras that PR makes extendedYear = temporalYear for all of them. temporal_rs just uses the extended year as arithmetic year.
The only potential divergence is for chinese/dangi.
I had previously proposed for Extended Year to be Temporal Year, but after we got pushback from ICU for changing a 25-year-stable behavior, Intl Era Month Code decided to define its own Temporal Year. Because of this, it should be the goal of ICU4X Extended Year to match ICU Extended Year, whose behavior you can see here:
https://github.com/unicode-org/icu/pull/3468/files
It appears to use the Amete Mihret number as the extended year for both ethiopian and ethiopian-amete-alem. If ICU4X doesn't do that, it is a bug.
And we've already established that ICU Extended Year for Chinese returns the one anchored in 2637 BCE, but Temporal wants it to be anchored at 1 CE.
(I'm also happy just deprecating/removing ICU4X Extended Year)
I filed an issue against ICU to track whether they want to make Extended Year align with ECMA:
https://unicode-org.atlassian.net/browse/ICU-23167
But I don't think we should hold our breath for that to be resolved.
If ICU4X doesn't do that, it is a bug.
Ah, I see. Seems like the divergence is just in ethiopic (and chinese/dangi where the concept works differently).
Should we expose a temporal_year?
In order to get this out sooner, I had made a suggestion for a 2.1 release:
- 2.1 is:
- Full support for the latest Temporal API
- Major improvements to time zone formatting
- Collator sort keys and performance improvements
- Experimental transliterator builder
- Time: Late August / Early September
- Code freeze August 25
- Crank on August 27
- 2.2 is:
- CLDR 48
- New ML Segmenter
- Maybe other things like graduated Relative Time
- Time: Novemberish
Discussion:
- @robertbastian I don't think the timezone changes are fully done, and I made the timezone changes assuming that they would be launched with CLDR 48 data. I don't think it is correct to launch them with 47 data. Beyond time zones, it's not clear that we have enough stuff to justify a release.
- @younies I'd like to add the units formatter for 2.1
- @Manishearth Most of these features have an active client. For example, Temporal_rs, which can't use git releases. Transliterator is iffy since we theoretically can patch it but Frank would prefer a clean release. It's not clear Units needs to be in the release.
- @Manishearth I think we have enough to justify a release with the stuff we want to put into it.
- @sffc Is there a way to make things experimental?
- @robertbastian It impacts datagen as well as the icu_time crate. Difficult to pull apart.
- @sffc I think it's fine if we ship with the patches we have on top of CLDR 47.
- @robertbastian I was not planning to release with the patch file. It is very specific to CLDR 47. If CLDR doesn't accept them, I don't want to include them in ICU4X. I won't be able to implement them in the next week. It also depends on whether we are able to implement the changes in ICU4C/ICU4J.
- @sffc Units should land in whichever release happens next after it is done.
- @robertbastian There should be an ICU4X release in sync with CLDR 48.
- @sffc Here is the CLDR schedule. I'm also okay having an ICU4X release in sync with beta, and we could release 2.1.1 if there are any changes between beta and final. https://docs.google.com/spreadsheets/d/1N6inI5R84UoYlRwuCNPBOAP7ri4q2CmJmh8DC5g-S6c/edit?gid=0#gid=0
- @robertbastian - we should not release with beta, there are usually quite a few data changes
- @sffc Could we have a
2.1-beta1release? - @robertbastian Eh, would it help anyone to do that?
- @Manishearth We could do patch releases, too. We don't have a specific policy on how big patch releases are. We could do cherry-picks for calendar and release experimental from main.
- @sffc If someone can put the chain of cherry picks together into the release branch, I'm okay with a patch release.
- @robertbastian - out of the 4 things sffc listed for 2.1, time zones should not be released before 48, experimental doesn't really need to be released imo because it's still in flux, we already discussed a release approach for collator, so we just patch release calendar
- @sffc I agree that Temporal is the main reason to consider a release. But the other problems could be solved as side-effects.
- @manishearth Agree that Frank's experimental problem isn't really fixed by a release. I think making an icu_calendar patch branch isn't a big deal.
- @sffc Might be weird to deprecate APIs in a patch release, though?
- @robertbastian It's a moot question if we decide to keep "extended year" naming
- @hsivonen I've worked out a way to manually patch in my icu_collator change, so I don't need a release for it right away
Conclusion:
- No full release from main before CLDR 48
- Be ready for 2.1 on Oct 22 (CLDR 48 release)
- The patch release process can still happen according to usual policy, including for icu_calendar (and icu_collator as discussed in a previous week)
See bikeshed discussion of monotonic_year in https://github.com/unicode-org/icu4x/pull/6800
ICU4X WG discussion:
- @robertbastian ICU has landed
extended_yearwhich I think makes our previous conclusion void, since it said that they weren't going to do it until CLDR 49 - @sffc The conclusion said that we would try adopting the new name across CLDR/ICU
- @sffc None of the names are good. They all have pros and cons. Because of the ICU change, I'm okay adding "extended" back to the pile of names to pick.
- @Manishearth I like arithmetic
- @nekevss I like monotonic
- @robertbastian I think arithmetic and monotonic are slightly better names, but maybe not worth the API churn
- @hsivonen I had a preference for arithmetic but not worth continuing the bikeshed
- @manishearth (also a preference for Arithmetic)
- @sffc Can we remove the getter from YearInfo? Then the name shows up in fewer places
- @manishearth I think it's useful; people shouldn't have to go through two specs and impl code to figure out that this is the same thing.
- @robertbastian We should document this in CLDR
- @sffc Yes, is there an issue? I think there is
Conclusion:
- Use
extended_year() - Document thoroughly (pointing to the temporal epoch year / arithmetic year as a source of truth)
- If ICU4C changes its mind (which hopefully we will know before 2.1 in CLDR 48 release) then we revisit renaming/deprecation
- We can point to CLDR as a source of truth if/when CLDR guarantees this.
LGTM: @sffc @robertbastian @manishearth (@hsivonen, @nekevss)