Skip to content
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

Closed
sffc opened this issue Jan 30, 2021 · 6 comments · Fixed by #445
Closed

Gregorian era identifier: ad or ce? #470

sffc opened this issue Jan 30, 2021 · 6 comments · Fixed by #445
Assignees
Labels
C-datetime Component: datetime, calendars, time zones T-core Type: Required functionality
Milestone

Comments

@sffc
Copy link
Member

sffc commented Jan 30, 2021

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:

  1. "ad" and "bc"
  2. "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?

@sffc sffc added discuss Discuss at a future ICU4X-SC meeting C-datetime Component: datetime, calendars, time zones labels Jan 30, 2021
@justingrant
Copy link

justingrant commented Jan 30, 2021

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:

Some academics in the fields of theology, education, archaeology and history have adopted CE and BCE notation, although there is some disagreement.[49] Several style guides now prefer or mandate its use.[50] The style guide for the Episcopal Diocese Maryland Church News says that BCE and CE should be used.[51]

In the United States, the use of the BCE/CE notation in textbooks was reported in 2005 to be growing.[45] Some publications have moved over to using it exclusively. For example, the 2007 World Almanac was the first edition to switch over to BCE/CE, ending a period of 138 years in which the traditional BC/AD dating notation was used. BCE/CE is used by the College Board in its history tests,[52] and by the Norton Anthology of English Literature. Others have taken a different approach. The US-based History Channel uses BCE/CE notation in articles on non-Christian religious topics such as Jerusalem and Judaism.[53]

In 2002, an advisory panel for the religious education syllabus for England and Wales recommended introducing BCE/CE dates to schools,[54] and by 2018 some local education authorities were using them.[55] In 2018, the National Trust said it would continue to use BC/AD as its house style.[55] English Heritage explains its era policy thus: "It might seem strange to use a Christian calendar system when referring to British prehistory, but the BC/AD labels are widely used and understood."[56] Some parts of the BBC use BCE/CE, but some presenters have said they will not.[55] As at October 2019, the BBC News style guide has entries for AD and BC, but not for CE or BCE.[57]

In June 2006, in the United States, the Kentucky State School Board reversed its decision to use BCE and CE in the state's new Program of Studies, leaving education of students about these concepts a matter of discretion at the local level.[58][59][60]

Also in 2011, media reports suggested that the BC/AD notation in Australian school textbooks would be replaced by BCE/CE notation.[61] The story became national news and drew opposition from some politicians and church leaders. Weeks after the story broke, the Australian Curriculum, Assessment and Reporting Authority denied the rumour and stated that the BC/AD notation would remain, with CE and BCE as an optional suggested learning activity.[62]

In 2013 the Canadian Museum of Civilization (now the Canadian Museum of History) in Ottawa, which had previously switched to BCE/CE, decided to change back to BC/AD in material intended for the public, while retaining BCE/CE in academic content.[63]

The style guide for The Guardian says, under the entry for CE/BCE: "some people prefer CE (common era, current era, or Christian era) and BCE (before common era, etc) to AD and BC, which, however, remain our style".[64]

I'd frame the decision like this:

  • If we want maximum name recognition and ease of use from global or self-taught developers without fancy academic credentials, then bc/ad is probably best
  • If we want to align with academic and scientific consensus and to avoid potential controversy, then ce/bce is probably best

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.

@sffc
Copy link
Member Author

sffc commented Feb 3, 2021

Thanks for the background. For the purpose of identifiers, I prefer taking the academic approach. In #445, I've adopted the ce/bce convention. Please note that this is only for the era identifiers; the rendered output will still show AD/BC depending on the locale and user preference.

justingrant added a commit to justingrant/proposal-temporal that referenced this issue Feb 3, 2021
justingrant added a commit to justingrant/proposal-temporal that referenced this issue Feb 3, 2021
justingrant added a commit to justingrant/proposal-temporal that referenced this issue Feb 4, 2021
justingrant added a commit to justingrant/proposal-temporal that referenced this issue Feb 4, 2021
justingrant added a commit to justingrant/proposal-temporal that referenced this issue Feb 4, 2021
@Louis-Aime
Copy link

Louis-Aime commented Feb 4, 2021

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).
Doing so, intercalendar code would be easier to develop, and philosophical problems would be settled culture by culture.

Anyway, a code remains a code, once fixed, people use it without asking questions. So let's go ahead.

@sffc
Copy link
Member Author

sffc commented Feb 4, 2021

2021-02-04: Go with recommendation in #470 (comment).

@sffc sffc added T-core Type: Required functionality and removed discuss Discuss at a future ICU4X-SC meeting labels Feb 4, 2021
@sffc sffc self-assigned this Feb 4, 2021
@sffc sffc added this to the 2021-Q1-m2 milestone Feb 4, 2021
@sffc sffc linked a pull request Feb 4, 2021 that will close this issue
@sffc
Copy link
Member Author

sffc commented Feb 4, 2021

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.

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.

cjtenny pushed a commit to tc39/proposal-temporal that referenced this issue Feb 8, 2021
* 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.
@justingrant
Copy link

For the purpose of identifiers, I prefer taking the academic approach. In #445, I've adopted the ce/bce convention. Please note that this is only for the era identifiers; the rendered output will still show AD/BC depending on the locale and user preference.

As requested, Temporal now uses ce/bce as era codes.

@sffc sffc closed this as completed in #445 Feb 12, 2021
ptomato pushed a commit to js-temporal/temporal-polyfill that referenced this issue May 6, 2021
ptomato pushed a commit to js-temporal/temporal-polyfill that referenced this issue May 6, 2021
* 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-datetime Component: datetime, calendars, time zones T-core Type: Required functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants