-
Notifications
You must be signed in to change notification settings - Fork 192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gregorian era identifier: ad or ce? #470
Comments
AD/BC is used more in colloquial/common usage while CE/BCE is used more in academia (history, archaeology, etc.) The TL;DR is that academics keep trying to get the general public to use CE/BCE, and the general public seems to consistently say "meh". So there's a lot of back-and forth between experts and non-experts. Wikipedia has a good summary of this dynamic:
I'd frame the decision like this:
I don't have a strong opinion about this choice. My only strong opinion is that we should clearly document the era codes for all built-in calendars. |
Thanks for the background. For the purpose of identifiers, I prefer taking the academic approach. In #445, I've adopted the |
I wonder whether the problem of choosing codes should refer to ideological unresolved debates. CLDR is more concerned with this. IMHO, the codes could be e0 and e1, meaning "ERA0" and "ERA1", the fall-back values of CLDR when the Locale does not give a result. This codes would just suggest that in e0 you count years backwards, as it happens in many (but not all) calendars. If you count with negative years, you do not need another era. And in the case of the ethiopic calendar, we would say "e1" for Amete Ahmet, "creation of world", and "e2" for Amete Mihret (incarnation). Anyway, a code remains a code, once fixed, people use it without asking questions. So let's go ahead. |
2021-02-04: Go with recommendation in #470 (comment). |
I agree with this sentiment, but the overwhelming feeling of others, based on the ICU4X design meeting last week, was that a human readable identifier for eras was more desirable. |
* Implement basic version of ICU non-ISO calendars * Skip Chinese calendar tests that fail on Node 12 Node 12 has outdated ICU data that causes DateTimeFormat.formatToParts not to emit the `relatedYear` part that's needed for Chinese and Dangi calendars. This commit skips these tests on Node 12. * Node 12 / Node 15 test fixes * Support M prefix on monthCode (see #1341) * Speed up non-ISO calendar tests about 2x * add "infectious" caching for `dateAdd`, where the result inherits the cache of the original object. For some calendars and some durations, this will speed up arithmetic by 50% or more. * switch some usage of `with` to `add` in tests to leverage faster `add` * when converting ISO<->calendar dates, cache the reverse direction too * remove perf optimizations that didn't help much * fix a bug (exposed by perf testing) with Chinese leap month codes * Fix pre-Meiji Japanese eras * Set dates before Meiji 1 to 'ad' or 'bc' eras * Work around various Chromium bugs * Fixed a few other era-related bugs * Constrain Hebrew leap months in non-leap year * Convert bc/ad eras to bce/ce unicode-org/icu4x#470 (comment) * Updated in response to @cjtenny review feedback * Optimize indian calendar and exact estimates Changes in response to review feedback by @cjtenny: * Indian calendar estmates are now exact * Exact estimates are more efficient now * Fixed some wrong comments * More updates from @cjtenny code review comments * Fix Indian calendar tests in Node 12/14 * Add new tests for Indian leap year and Indian ICU bugs * Refactor ICU bug checking to be more generic * Update outdated comments * Remove redundant validation * Catch eraYear/year and month/monthCode conflicts * Fix non-ISO constrain/reject logic * Ensure that invalid `month` is constrained or rejected per options * Ensure that invalid `monthCode` is always rejected (fixes #1349) * Add tests for PlainMonthDay to verify the above and to ensure that leap days and leap months are constrained accurately * PlainMonthDay({month: Infinity, day}) handling The previous commit failed the`PlainMonthDay({month: Infinity, day})` test because 'MInfinity' is obviously invalid. This commit changes the "calendar omitted" path of ToTemporalMonthDay (which previously added a `monthCode`) to add a `year` (1972) instead which won't cause the MInfinity problem. While we're in the neighborhood, this commit also adds one more test for round-tripping PlainMonthDay values to/from ISO strings.
As requested, Temporal now uses |
* Implement basic version of ICU non-ISO calendars * Skip Chinese calendar tests that fail on Node 12 Node 12 has outdated ICU data that causes DateTimeFormat.formatToParts not to emit the `relatedYear` part that's needed for Chinese and Dangi calendars. This commit skips these tests on Node 12. * Node 12 / Node 15 test fixes * Support M prefix on monthCode (see #1341) * Speed up non-ISO calendar tests about 2x * add "infectious" caching for `dateAdd`, where the result inherits the cache of the original object. For some calendars and some durations, this will speed up arithmetic by 50% or more. * switch some usage of `with` to `add` in tests to leverage faster `add` * when converting ISO<->calendar dates, cache the reverse direction too * remove perf optimizations that didn't help much * fix a bug (exposed by perf testing) with Chinese leap month codes * Fix pre-Meiji Japanese eras * Set dates before Meiji 1 to 'ad' or 'bc' eras * Work around various Chromium bugs * Fixed a few other era-related bugs * Constrain Hebrew leap months in non-leap year * Convert bc/ad eras to bce/ce unicode-org/icu4x#470 (comment) * Updated in response to @cjtenny review feedback * Optimize indian calendar and exact estimates Changes in response to review feedback by @cjtenny: * Indian calendar estmates are now exact * Exact estimates are more efficient now * Fixed some wrong comments * More updates from @cjtenny code review comments * Fix Indian calendar tests in Node 12/14 * Add new tests for Indian leap year and Indian ICU bugs * Refactor ICU bug checking to be more generic * Update outdated comments * Remove redundant validation * Catch eraYear/year and month/monthCode conflicts * Fix non-ISO constrain/reject logic * Ensure that invalid `month` is constrained or rejected per options * Ensure that invalid `monthCode` is always rejected (fixes #1349) * Add tests for PlainMonthDay to verify the above and to ensure that leap days and leap months are constrained accurately * PlainMonthDay({month: Infinity, day}) handling The previous commit failed the`PlainMonthDay({month: Infinity, day})` test because 'MInfinity' is obviously invalid. This commit changes the "calendar omitted" path of ToTemporalMonthDay (which previously added a `monthCode`) to add a `year` (1972) instead which won't cause the MInfinity problem. While we're in the neighborhood, this commit also adds one more test for round-tripping PlainMonthDay values to/from ISO strings.
On the business logic layer, it will be necessary to have a string identifier for the modern era and pre-modern era of the Gregorian calendar. Given the decision on the Japanese era (tc39/proposal-temporal#526), where we went with an English transliteration as the identifier string, it seems we have two main choices for the Gregorian eras:
"ad"
and"bc"
"ce"
and"bce"
For the purposes of formatting and locale data lookup, we will need to disambiguate based on user preference, but that should happen very low in the formatting step. The date time input model, on the other hand, should not vary based on user preference.
@pedberg-icu @yumaoka @Manishearth @justingrant thoughts?
The text was updated successfully, but these errors were encountered: