Canonical era names for gregory should be ce/bce or ad/bc

[justingrant]

Per discussion in #9, the current proposed CLDR data will use gregory and before-gregory as the code for the eras of the gregory calendar, but per #9 (comment), ECMAScript is free to choose any alias (or the code) as the canonical identifier that's returned by the Calendar.p.era getter.

There are only two CLDR calendars that make heavy use of eras: Japanese and Gregorian. For Japanese, there's a separate discussion that @Manishearth is driving.

I'd strongly suggest that this proposal's spec should use ce and bce as the canonical era identifiers for gregory, because:

• Those names are more familiar to people encountering them in a debugger or in other peoples' code. era: 'gregory' or era: 'pre-gregory' will very likely require consulting the docs to figure out what it means.
• pre-gregory introduces ambiguity: does it mean "BC/BCE" or "Julian" ?

[sffc]

While I think this is a discussion worth having, my initial position is that ECMAScript should use gregory/pre-gregory rather than ce/bce, because:

1. Gregorian favoritism. There are other calendars that make use of multiple eras, including R.O.C., Coptic, and Ethiopian. There is the Indian calendar whose era is often called Saka. If we make special names only for Gregorian, we are either implying that eras are uniquely fundamental to the Gregorian calendar system more so than the others (see the next bullet point) or that the authors of this proposal understand Gregorian better and are therefore leaving all other calendars as default while giving Gregorian special treatment. A primary purpose of my proposal to derive era names from the calendar identifier rather than the era display name was to remove the need to make decisions like this.
2. It's not clear that Gregorian is really any more special than other multi-era calendar systems. Although BC/AD is a well-known convention, many users will only ever encounter modern dates, for which they get era: "gregory", which is a bit odd but not misleading and therefore just fine.
3. As @Louis-Aime noted in other threads in this repo, the concept of "BC" in the Gregorian calendar is fraught, because "BC" is universally understood to refer to Julian dates. "pre-gregory" is a special concept that refers to the Proleptic Pre-Gregory era, something which only exists in computing and nowhere else.
4. I'd prefer to not diverge from CLDR, though we could upstream this to CLDR if we act quickly.

Now, I am open to adopting a convention other than "pre-..." if desired. This could address the second of @justingrant's two reasons for preferring ce/bce.

[Manishearth]

There are other calendars that make use of multiple eras [....] R.O.C., Coptic, and Ethiopian. There is the Indian calendar whose era is often called Saka

The Indian calendar is single-era.

I'm actually fine with having the default eras for all calendars with 2 eras being the named ones, where there's a clear candidate for codes. I think it would work pretty well.

(One issue about Coptic is that I'm not sure if there's a clear candidate for the code)

because "BC" is universally understood to refer to Julian dates

This isn't quite true, it's understood that way in scholarly circles, and normal people either don't know of the difference or depend on context. Especially in programming contexts where there's a rich history of using proleptic Gregorian, I would very much say it's not "universal".

And these codes are being designed for programmers. I think the proleptic Gregorian calendar "only existing in computing" is actually a strong reason as to why "bc" for proleptic is fine. Perhaps not ideal, but not terrible. I don't think there's a danger of programmers seeing this and thinking it's not proleptic, and I don't think there's a chance that programmers with misconceptions about prolepticness seeing pre-gregory and thinking to check that, so I don't think it wins us much on the educational front (and in general I'm not a fan of the tactic of making one thing more obscure in order to draw attention to something else).

Basically I really don't think the discoverability of the proleptic issue is helped by "pre-gregory", nor do I think it is hurt by "bc".

[justingrant]

My main feedback here is that we should optimize for discoverability and minimize the need for programmers to look stuff up in order to understand someone else's code or to understand an object in the debugger. If any calendar has widely-understood names for something, then using those names makes things easier for developers and increases the chance that developers will actually use the APIs we've been designing.

This issue was only about Gregorian because that's the calendar I know best. If there are other calendars like indian that have widely-understood era names like saka, then we should use those names too!

If a calendar doesn't use eras heavily enough to have a well-recognized name for the era(s), then naming eras after the calendar sounds OK to me. But we shouldn't force all calendars except Japanese to lowest-common-denominator discoverability.

"bc" for proleptic is fine

I did a quick check for prior art:

• Java/Kotlin (old API): BC/AD
• Java/Kotlin (new API): BCE/CE
• .NET: ADEra (it's a boolean)

I'd be OK with either ad/bc or ce/bce. The key is to pick something that's already widely known by programmers. Either pair of names is far more discoverable and less confusing than gregory/pre-gregory.

I changed the title of this issue accordingly.

1. Gregorian favoritism.

We're planning to use colloquial, easy-to-understand names for Japanese eras. Why are we practicing Japanese favoritism? 😄

Seriously though, using discoverable names isn't favoritism; it's being helpful to programmers by not requiring them to learn concepts that they otherwise don't have to learn.

BC/AD is a well-known convention, many users will only ever encounter modern dates, for which they get era: "gregory", which is a bit odd but not misleading and therefore just fine.

Using familiar names might also help with discoverability of calendar features overall. For example, if a programmer doesn't know what era means, then seeing a recognizable value in the debugger might help them figure it out without having to consult the docs: "Oh I get it, era is the AD/BC thing!". This is similar to how it's much easier to understand what hourCycle is when you see that its value is h23.

Also, many calendars have an English name (e.g. "Indian National Calendar") and another name in a local language ("Saka calendar"). Using a different name for the era might help clarify what's going on for programmers who'd otherwise be confused.

I'm not a fan of the tactic of making one thing more obscure in order to draw attention to something else

Specifically, the reason why this approach often struggles is because programmers (like any humans) react to confusing things in different ways. Some will investigate more. Others will not bother; they'll just guess. Others will simply avoid things that look confusing or unknown. Even if the "investigate more" group is large, the other groups are failure cases and are never tiny. Obscurity will always lose a non-trivial percentage of users. It's risky.

[gibson042]

As a data point, I am a longtime participant in the Temporal proposal and still ran into this issue myself, thinking that an "Input era … doesn't match calculated value gregory" error message was a categorical bug in the polyfill because "gregory" is the name of a calendar, not an era.

[gibson042]

Following up on the above, I would expect instead that era code names are fundamentally independent of their calendar, so in the Gregorian calendar the era codes are either "ce" vs. "bce" or "ad" vs. "bc", while in other calendars that have an epoch which implicitly divides eras but no generally-recognized concept of eras (e.g., Coptic/ROC) the era codes are something like "primary"/"default"/etc. vs. "inverse" (the latter also being applicable to Japanese and Ethiopic, and the former being applicable to every implicit-era calendar except maybe Ethiopic [which could arguably use e.g. "aa" to identify its primary era]).

And then, if uniqueness across calendars is desired, all of those codes would instead be prefixed with the calendar to which they apply ("gregory-ce", "japanese-inverse", "coptic-primary", etc.).

[Manishearth]

As a data point, I am a longtime participant in the Temporal proposal and still ran into this issue myself, thinking that an "Input era … doesn't match calculated value gregory" error message was a categorical bug in the polyfill because "gregory" is the name of a calendar, not an era.

Honestly I think this is a fault of the error message more than the sepc here.

[justingrant]

I really like @gibson042's proposal above to include a calendar ID prefix. It will be very discoverable and obvious for the vast majority of users who are unfamiliar with the intricacies of calendars and eras.

You'd lose the ability to share the same-IDed era across calendar, but IMO this is a feature not a bug, because having the same name for eras across calendars makes it harder for developers to understand what they're looking at when they're viewing the era ID without the calendar ID too.

[sffc]

Something like this could be workable if we think ECMAScript users will make the category error @gibson042 noted.

I'm not fully convinced. The reasons for the current proposal still stand.