search

tc39 / proposal-intl-era-monthcode

To specify necessary details about era, eraYear and monthCode usage with Temporal in internationalization setting (for calendars other than "iso8601").
https://tc39.github.io/proposal-intl-era-monthcode
MIT License
3 stars 3 forks source link

Era issue for the Gregorian calendars. #5

Open Louis-Aime opened 2 years ago

Louis-Aime commented 2 years ago

Let me first make a historical reminder. The Gregorian reform by Gregorius XIII changed the calendar from October 1582. It did not change any date before that. Therefore the Gregorian calendar follows the Julian calendar's rule up to October 4th, 1582 (1582-10-14), and then follows the rule established by Gregorius.

However, in all European countries except Italy, Spain and Portugal, the date of switchover to Gregorian was later than 1582-10-15. In France, it was on 1582-12-20, in United Kingdom on 1752-09-14. There are around 60 different dates of switchover to the Gregorian calendar.

When giving a date for any event before 1582, the general public implicitly uses the Julian calendar, and more precisely the origin of the years defined by Dionysius Exiguus in the 6th century. The years before that year 1 are counted backwards starting from 1, and are "tagged'" B.C. or B.C.E. in English, meaning "before Christus" or "before common era", or in a similar way in other European languages.

All Unicode calendars derived from the Gregorian calendars use the Julian calendar until October 4th, 1582. You may check for buddhist, japanese and roc and see how they display 0001-01-01, or 1582-10-14.

Many years after the Gregorian reform, astronomers introduced the "year 0" (Jacques Cassini in 1740) to facilitate computations. They still used the Julian calendar for events before 1582.

The "proleptic Gregorian calendar" was introduced very recently in the context of "computerisation", in order to facilitate computation of dates. In all cases I know, including in Javascript, the user specifies any year using algebraic numbers, i.e. with a zero year and negative numbers. I have an interesting source for this in the documentation of Python (Python general calendar-related functions):

The functions and classes defined in this module use an idealized calendar, the current Gregorian calendar extended indefinitely in both directions. This matches the definition of the “proleptic Gregorian” calendar in Dershowitz and Reingold’s book “Calendrical Calculations”, where it’s the base calendar for all computations. Zero and negative years are interpreted as prescribed by the ISO 8601 standard. Year 0 is 1 BC, year -1 is 2 BC, and so on.

I have found no case where the proleptic Gregorian calendar is used (not just defined) with eras and years counted backwards. On the contrary, the ISO 8601 made it clear that the proleptic Gregorian calendar could be used for interchange, but in this case the year should be an algebraic number, so that no era indication is necessary.

As I can see from the conversation of Issue #1, there are discussion about what the era codes for the gregory calendar should be. IMHO, very simple: as it is a proleptic Gregorian calendar, no code at all, since it has a single era. And so are the buddhist and roc calendars. As for japanese, there is no era with backward-counted years.

The real expectation is cited here : https://github.com/FrankYFTang/proposal-intl-era-monthcode/issues/1#issuecomment-1185996042 :

N.b. in ICU4X gregory is proleptic gregorian, though we are considering having a calendar with a configurable switchover date (cc @sffc).

Today's gregory calendar does not meet the expectations of researchers in history of Europe.

This configurable calendar is highly expected in order to cover the needs for historical applications. IMHO, it should have 3 eras, with the following codes:

I already designed a mock-up for this configurable calendar. It needs another one: the pure Julian calendar, which has no official use anymore, except in communities. I believe it would be highly appreciated.

sffc commented 2 years ago

Hmm.

How would one render dates in the 3-era Gregorian calendar for human consumption?

For example, you might have two dates expressed as

The two dates represent different days. How should they be rendered?

sffc commented 2 years ago

The Wikipedia page has some examples: https://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates

Perhaps the following rendering should be used:

  1. "1800 B.C."
  2. "1800 O.S." (Old System)
  3. "1800 A.D." or "1800"
Louis-Aime commented 2 years ago

I would rather suggest the following:

  1. "1700 B.C." meaning the 1700th year before Jan. 1st, 1; the date is expressed in Julian calendar.
  2. "1700 A.D." meaning that the date is expressed in Julian calendar, although it comes well after 1582. Same era and same reckoning system as "1400 A.D." for instance.
  3. "1700 N.S." meaning that the date is expressed in Gregorian calendar.

As a possible variant, we could use "O.S." instead of "A.D." for all dates after 1582-10-15 that are expressed in Julian calendar. But this is not necessary, as no confusion is possible. Or we could have "O.S." as a variant for "A.D." from year 1 until date of switchover.

With the eraDisplay option, "1700 N.S." becomes "1700" except if author specifies eraDisplay="always".

sffc commented 2 years ago

For era codes, how about:

sffc commented 2 years ago

I opened https://unicode-org.atlassian.net/browse/CLDR-16113 to discuss display names.

Louis-Aime commented 2 years ago

It is worth noting that many countries switched to Gregorian on 1700-03-01: most of German and Scandinavian states. Here are some examples of how IMHO date expressions should be understood and date should be rendered with this calendar instance. Let's assume that the eraDisplay option is developed and set to "auto" (the default value). I give the date value in ISO 8601 and an expected rendered values. Note that the eraCode can be "guessed" in many circumstances.

Louis-Aime commented 2 years ago

For era codes, how about:

  • gregory = new system (current era)
  • julian = old system
  • pre-gregory = BCE according to proleptic Gregorian
  • pre-julian = BCE in practice according to Julian

pre-julian , julian, gregorian, in this order, are fine, for a non-proleptic generic Gregorian calendar. Since the date of switchover shall be on or after 1582-10-15, there is no room for pre-gregory.

In fact, you can implement the non proleptic Gregorian calendar's computations by referring to the era code's index, and never to the code value. So authors who do not like those codes will just create a new calendar using an implemented model, and change the calendar.era() method.

pre-gregory code value could be used for another calendar: a proleptic Gregorian calendar that used a 1-y counting style for years prior to 1. But there is no such calendar in the real world. Except gregory and iso8601 in the ICU. But they are not used for dates before 1582.

sffc commented 2 years ago

CC @Manishearth

Manishearth commented 2 years ago

I think the ultimate tension here has to do with user expectations.

The average user, when using this, will likely expect to see negative counting and BCE eras. There is something to be said for the average user also expecting the non-proleptic calendar, however people who do know about the difference would then know that a switchover date is needed.

So I'm not sure I agree with the premise that BCE for the proleptic Gregorian calendar doesn't make sense since it has no dates in that era.

Today's gregory calendar does not meet the expectations of researchers in history of Europe.

I also do think there are two separate questions being discussed here:

  1. How should users deal with historically accurate era epochs including switchovers?
  2. How should the proleptic Gregorian calendar handle the pre-CE era?

In general I think there's already wide agreement on 1. that gregory is the proleptic calendar and thus not intended to meet the expectations of researchers. Rather, a separate calendar (or multiple calendars) might be introduced.

So I think we should stick to solutions that don't attempt to retrofit that into gregory, unless you want to make a strong case for that solution in particular.

This configurable calendar is highly expected in order to cover the needs for historical applications. IMHO, it should have 3 eras, with the following codes:

  • bc (or bce - although I do not understand why one should avoid citing Christus... after all, no one is shocked with the allusion to Buddha in the Buddhist era of the Buddhist calendar);
  • os or as (Old Style, or Ancient Style, meaning that the Julian reckoning system is used even after 1582);
  • ns (New Style, conforming to ISO8601).

Hmm. So I don't think overlapping era codes makes sense here. The Ethiopian calendar already does this, however it still segregates these by ethiopic and ethioaa.

The era codes are used for both input and output: you should be able to construct dates given an era code, and you should be able to get the era for a given date, and there should only be one correct answer given the situation.

As such I don't think the answer for this is in era codes. I think the answer for this is instead in having two era codes (bce/ce), that are all shared amongst three calendars:

Then, you can have full clarity both when constructing and formatting dates. Temporal already provides conversion utilities between dates, you can construct dates based on the calendar matching your source data, and you can format dates based on the calendar matching the format you need. This is probably the cleanest split, instead of having non-roundtrippable eras.

sffc commented 2 years ago

I would like to retain the property that era codes uniquely identify the day. This would mean we would need to define ce and bce to be proleptic Gregorian. Alternatively, we just use gregory and pre-gregory for that purpose and remove all ambiguities.

Louis-Aime commented 2 years ago

I think the ultimate tension here has to do with user expectations.

IMHO our objective is to help expert users (those who are author of applications) give to naive ones (final users) exact data, and perhaps help them understanding the intrinsic complexity of the Gregorian calendar.

Today's built-in calendars are not suitable for this. Today, if a user states ca=iso8601 and enters -000001-06-01, the display will be "1 June 2 BC", whereas the ISO 8601 standard explicitly states that negative years should be used here. So iso8601 calendar does not render the calendar specified by ISO 8601.

Your suggestion of having three calendars, julian, julian-gregorian, iso8601 is probably a very good way in order to separate issues. These calendars would share many display names, at least months and weekdays. TMK the situation of the "real" calendar of Caesar BC 45 to CE 8 is not totally known, whereas the "proleptic" version of the julian calendar has been used in many astronomical documents. Probably a julian-greg-astro with 0 and negative years, and with fixed switchover on 1582-10-15, would help understanding a big number of astronomical documents;

  1. How should users deal with historically accurate era epochs including switchovers?

At the end, this is a question to ask to expert users, i.e. historians. My understanding is that they add a qualifier to all ambiguous date expression (B.C. to say that years are counted backwards from year 1; O.S. to say that, whereas the date expression is after 1582-10-15, the date is under julian reckoning system; N.S. to say that the date is in Gregorian, although the context is e.g. England in the 17th century). So it seems wise to use the era field, the one that resolves ambiguity among date expressions. I can tell you that this may be done with Temporal.

  1. How should the proleptic Gregorian calendar handle the pre-CE era? Very simple: using 0 and negative years, as prescribed by the ISO 8601 standard. I know no user who would handle a pre-CE date using the proleptic Gregorian calendar otherwise than using 0 or negative numbers for years. I may be wrong, but then I would like to have examples.

Then, you can have full clarity both when constructing and formatting dates. Temporal already provides conversion utilities between dates, you can construct dates based on the calendar matching your source data, and you can format dates based on the calendar matching the format you need. This is probably the cleanest split, instead of having non-roundtrippable eras.

I am together with you on this. But the eras I proposed are not more "non-roundtrippable" than existing ones. Let's take an example under Temporal:

eti1 = Temporal.PlainDate.from( {era : "era0", eraYear : 5502, month : 6, day : 1, calendar : "ethiopic" }) //> Temporal.PlainDate {_repr_: 'Temporal.PlainDate <0010-01-24[u-ca=ethiopic]>'} eti1.era //> 'era1' eti1.eraYear //> 2

Here too, the input era is "era0" and the output is "era1". Isn't an era code overlapping another ?

The real problem with my example (OS/NS) is that here era does not indicate an origin for the number of years, but a reckoning system for date, i.e. a "basic" calendar system. But this matches a real use case.

Manishearth commented 2 years ago

TMK the situation of the "real" calendar of Caesar BC 45 to CE 8 is not totally known, whereas the "proleptic" version of the julian calendar has been used in many astronomical documents.

yeah this is correct, it's why I'm wary of suggesting we do a non-proleptic julian calendar.

My understanding is that they add a qualifier to all ambiguous date expression (B.C. to say that years are counted backwards from year 1; O.S. to say that, whereas the date expression is after 1582-10-15, the date is under julian reckoning system; N.S. to say that the date is in Gregorian, although the context is e.g. England in the 17th century)

To me this seems like a choice of formatting locale.

Here too, the input era is "era0" and the output is "era1". Isn't an era code overlapping another ?

Yes, but the purpose of those codes is not to overlap, this is just a quality of life thing on top of an existing era systems. Whereas here they do overlap.

Either way, if you're in favor of the multi-calendar system, this discussion is moot, since the multi-calendar system separates all these concerns pretty nicely. julian-greg-astro with fixed switchover seems nice.