tc39 / proposal-intl-eradisplay Goto Github PK

The eraDisplay proposal came initially from a ticket at CLDR where I was worried that era field was displayed even if the author did not explicitly ask for it. This post is still in "new" state the day I'am writing this post. Seeing no reaction, I designed the first draft of the eraDisplay proposal in May 2020.

The presently distributed version of CLDR reacts in different ways when era option is not defined where year is. These is quite visible and easy to test on the proposal's moke-up on GitHub Pages. With "en-GB", when era is set to undefined for ethiopic or coptic, display is as if month was undefined !

I suspect there are certain "shortcuts" in designing the date display patterns that yield to unwanted effects.

I intend to issue a new post on CLDR on this issue.

I think this is reasonable except for the splitting of era and year. In Japan, the current year is either 2022 or R4 (令和4年) but not just 4(年). Beyond just awkwardness, this would have the potential of incurring confusion between calendar years and year-length durations (as, depending on context, 4年 could also mean "4 years").

Originally posted by @rkirsling in #7 (comment)

The proposal has been accepted as Stage 1. This means that we should migrate this repo from Louis-Aime/proposal-intl-eradisplay to tc39/proposal-intl-eradisplay.

The first step is to transfer the repo to me, and then I will move it to tc39.

As proposed on Dec. 8, here is the way Intl.DateTimeFormat handles eraDisplay at contruction time.

1. As Intl.DateTimeFormat is constructed, a resolved eraDisplay field is evaluated.
   1. value is set to "never" or "always" if it was specified so.
   2. else, including if no eraDisplay was passed, value is set to "auto".
   3. except if value was set to "never", era option is set to "short" if it was undefined.
   4. finally, if "auto" and if the year option is undefined, value is set to "never".

In other words:

• auto feature shall work most of the time, without changing user's code.
• If [[year]] is not to be displayed, by default [[era]] will not be displayed even if era was specified to some value.

Please note that, as of today (and I'm not sure this is in line with the original intention), if the only asked option is era, all date parts are displayed. With the proposed option, setting era only would result in having all date fields except era !

I thought that only if all date-time option fields were undefined the day month year combination was assumed. (see e.g. in MDN As of today, it is not possible to display the era alone. Something remains to be done here ("Best fit" resolving option ?).

That said, only very demanding users having rather special requirements (displaying era and other part of the date, except year) would have to change their code.

A suggestion from @mihnita:

Currently CLDR has data in some locales to render Gregorian dates with two-digit precision, such as "8/30/24" which currently means "August 30, 2024" in American English.

However, the elided century is only valid if discussing dates that are not too far into the past or future. For example, it is probably understood what you mean when writing "1/1/75" (1975) or "1/1/30" (2030) but something like "1/1/40" might be ambiguous between 1940 and 2040. (I don't know if 40 is actually the official cutoff, but it serves as a good example).

This makes me think that maybe we want to have an algorithm that can impact year precision, not just era display.

This proposal was designed starting from these discussions.

I brought up this topic at the CLDR Design meeting today. There was a proposal that we could specify the display defaults with a data-driven approach. For example, in the CLDR XML:

        <calendar type="gregorian">
           <calendarSystem type="solar" />
           <eras>
               <era type="0" end="0-12-31" code="gregory-inverse" aliases="bc bce"/>
               <era type="1" start="1-01-01" code="gregory" aliases="ad ce" suppressFrom="1500-01-01"  suppressTo="10000-01-01"/>
           </eras>
        </calendar>

where suppressFrom and suppressTo are new attributes. I suggested 1500 somewhat arbitrarily to correspond to the European renaissance period.

@Louis-Aime thoughts?

The principle behind the optional display of era names also carries to years and even smaller fields. For example, as a date approaches, one might say,

1. "November 20, 2021 CE"
2. "November 20, 2021" if the current era is CE
3. "November 20" if the current year is 2021 CE
4. "The 20th" if the current month is November 2021 CE

The question is, should we keep this proposal limited to just eraDisplay, or should we make it more general?

The result of the method will have a different number of components, depending on the date parameter.

If eraDisplay 's resolved value is "never" or "always", the structure of the formatted date is known at construction step, there is nothing new.

If eraDisplay is "auto", the method shall establish whether era shall be displayed or not. Date.now is computed, its [[era]] slot is compared to date's, and finally [[era]] is displayed if and only if the [[era]] slot's values differ.

After this decision is taken, one way is to choose the suitable date pattern. But normally this choice is done when DateTimeFormat is constructed (am I right ?).

The other option is to have a pattern with era handy, and if necessary to suppress the era part and the dependent literal if there is one. In this case, all patterns with years (y, Y etc.) would have an era part (g, G etc), which could simplify the number of patterns for each locale. Then the algorithm is easy to understand.

However, for certain locale (en-US, fr, most European ones...) there is a difference between date patterns with 2-digit fields and no era, and the same with era:
01/01/2020 versus 01 01, 2020 AD.
In my opinion, there should not be any difference. Both should be written with slashes. But I might be wrong.

There are several calendars that currently display the same era for both positive and negative years. Is this expected? If not, then what should be the era name for negative years, or should it be blank?

Examples:

const calendars = ['indian', 'buddhist', 'persian', 'islamic'];
const dates = [new Date('-010000-01-01T00:00Z'), new Date('2020-01-01T00:00Z')];
for (const date of dates) {
  console.log(date.toISOString());
  for (const calendar of calendars) {
    console.log(`${calendar}: ${date.toLocaleDateString('en-US', {calendar, timeZone: 'UTC'})}`);
  }
}

/* output: 
-010000-01-01T00:00:00.000Z
indian: 6146/12/-10583 Saka (ignore known bug with month number)
buddhist: 3/18/-9457 BE
persian: 10/10/-10622 AP
islamic: -6/15/-10947 AH

2020-01-01T00:00:00.000Z
indian: 10/11/1941 Saka
buddhist: 1/1/2563 BE
persian: 10/11/1398 AP
islamic: 5/6/1441 AH
*/