Update various era codes

[ryzokuken]

Recently after some discussion in TG2 we concluded the era codes for a number of calendars. This PR addresses all of those issues and updates the "location" metadata field.

[Manishearth]

cc @robertbastian

[sffc]

unicode-org/cldr#4519 is mostly done but waiting on some questions to be answered, and it should be considered the source of truth for era codes.

[ptomato]

I think we should proceed merging this without the era codes that are equal to the calendar names, and without the *-inverse codes. As per #12, the consensus seems to be that nobody wants them. They are also not in unicode-org/cldr#4519, and although that is still under discussion, there was only one dissenter who has not followed up. So if CLDR changes back, we can add the aliases back in another PR.

[ptomato]

I'm wondering what we should do with chinese and dangi, as unicode-org/cldr#4519 deletes the era codes. Delete them from the table? (we may have to check the assertions around CalendarSupportsEra)

[sffc]

I'm wondering what we should do with chinese and dangi, as unicode-org/cldr#4519 deletes the era codes. Delete them from the table? (we may have to check the assertions around CalendarSupportsEra)

See the recommendation in #28

[sffc]

So if CLDR changes back, we can add the aliases back in another PR.

ECMA could still decide to omit those aliases, although then we would be diverging from CLDR which is undesirable.

[ryzokuken]

Thanks for all the suggestions above, I updated the PR to remove all the era names that matched the calendar or were of the type <calendar>-inverse in favor of the more commonly used era acronyms. The exception to this was the ROC calendar where the ROC era (and BROC) is the correct transliteration of the localized era name.

[ryzokuken]

Updated the codes to match exactly everything in unicode-org/cldr#4519 with the exception of Chinese and Dangi which no longer have era codes in CLDR. What should we do here? Should I no longer list the era codes for those calendars, stick to the ones named exactly the same as the calendar or switch to BCE and CE (like we do for some interval in the Japanese calendar)?

[ptomato]

Updated the codes to match exactly everything in unicode-org/cldr#4519 with the exception of Chinese and Dangi which no longer have era codes in CLDR. What should we do here? Should I no longer list the era codes for those calendars, stick to the ones named exactly the same as the calendar or switch to BCE and CE (like we do for some interval in the Japanese calendar)?

See the discussion above: #39 (comment)

[ptomato]

Also delete the chinese and dangi rows as per Shane's recommendation in #28, and check that that doesn't mess up any assertions with CalendarSupportsEra

[anba]

The changes from unicode-org/cldr#4581 to add bh for Hijri calendars are also missing.

[ryzokuken]

Okay I believe I have addressed the recent comments in the last few commits. The entire diff is a bit messy but the individual commits should be easier to review.

[anba]

Do we actually need any entries for calendars which don't use multiple eras? For example buddhist and hebrew don't have eras (note: plural "eras", not singular "era"), so per https://tc39.es/proposal-temporal/#sec-temporal-calendar-date-records:

[[Era]] A lowercase String value representing the date's era, or undefined for calendars that do not have eras.

This also matches the implementation in the spec polyfill and in Firefox:

js> new Temporal.PlainDate(2025, 1, 1, "buddhist").era === undefined
true
js> new Temporal.PlainDate(2025, 1, 1, "hebrew").era === undefined   
true

[ryzokuken]

@anba I suppose it's an open question. My personal opinion is that it matters. For instance the Hindu calendar might just have the "shaka" (transliteration is hard, my personal experience is to see it referred to more often as "saka") era but it is an era in that calendar (and therefore reveals important information) and formatting the date without it might confuse a reader.

Note that in an interface or a formatted result it might not be easy for the reader in some contexts to tell which calendar a date is supposed to be in and therefore the "shaka", "be" or "am" suffix for the era might be necessary for the reader to be able to discern a date in a calendar from (Proleptic) Gregorian dates which are generally formatted without an era code outside of history-related contexts.

[anba]

I don't think formatting is relevant for the era and eraYear accessor properties in Temporal. An era specifier is necessary to avoid ambiguous results when only a year is given. For example "year 1 in the Gregorian calendar" requires an era specifier to able to differentiate between 1 AD and 1 BC. But saying "year 1 in the Hebrew era in the Hebrew calendar" is redundant, because aren't multiple eras and therefore it's unambiguous when instead "year 1 in the Hebrew calendar" is used.

Formatting is also locale-dependent, see tc39/proposal-temporal#2899 for examples where dates are formatting without eras when using locales which actually use the calendars.

[ryzokuken]

But saying "year 1 in the Hebrew era in the Hebrew calendar" is redundant, because aren't multiple eras and therefore it's unambiguous when instead "year 1 in the Hebrew calendar" is used.

You're right about this but about the era accessor I personally disagree that returning undefined is the correct behavior just because only one well-defined era exists. My view on the subject is that since there is indeed a well-defined era with a name we should be returning that because that's what the user would probably expect. It might not be necessary to tell dates apart but it's still the correct thing.

To be more specific, I'm thinking along the lines of the question: "does the calendar have eras? which era is currently ongoing?". For instance CalendarSupportsEra would return false if we remove these calendars which to me sounds like the incorrect result, even if there's a singular era.

[ptomato]

👍 All good

[ptomato]

@anba Re. dropping eras in Temporal for calendars with only one era, I personally like your suggestion better and I did it that way in the reference code as you mentioned, but I would prefer to go with this approach for two reasons:

1. It has TG2 consensus already
2. Dropping the eras would be an extra decision point in ECMA-402 to apply on top of the information coming from CLDR supplementalData.xml. Not editorializing on top of that data is a factor that I weight very heavily.

I'm going to merge this and if you feel strongly that it should be otherwise, please open a new issue for dropping the lone eras and advocate for it in TG2.

[justingrant]

Sorry for being late to the party, but I agree that showing single eras seems helpful, specifically for discoverability in some calendars where the era code might clarify what the calendar means. I'm specifically thinking of indian where the era name shaka can help clarify that it means the Indian National Calendar and not older Indian calendars. But this may also apply to Islamic calendars where AH is well known, and perhaps buddhist where "BE" might also help distinguish between other calendars.

[sffc]

Yes, we should return the era code for single-era calendars. A rule of thumb is that if you can talk about the era (if the era has a name), then the era is a real thing and should have an identifier. There is no era code for Chinese because there is no such thing as an era in that calendar. But Coptic, Buddhist, Hebrew, etc., all have an era with a well-defined name (Anno Martyrdom, Buddhist Era, Anno Mundi).