Option eraDisplay in Intl.DateTimeFormat()

[Louis-Aime]

With the versions of Intl.DateTImeFormat currently (April 2020) implemented in Firefox and Chrome, with most locales, for all calendar other than gregorian, chinese and dangi, a date with a year component shall be displayed with the era component, even if not wanted by the programmer:

let t = new Date("2020-04-04");
var dtf = new Intl.DateTimeFormat(
"en-u-ca-coptic", {year : "numeric", month : "long", day : "numeric"});
dtf.format(t);  // "Baramhat 26, 1736 ERA1"

For the coptic calendar and for years after 284 AD, displaying the era is unnecessary. Moreover, the name of the era is not even properly defined in CLDR for "en", so it would be better to hide it.

On the other hand, it is a current practise to display the era only if the date displayed is not the present era. For instance:

• it is necessary to display BC in the julian calendar for dates before 1/1/1, because years before 1 are counted backwards: year 1 BC is before 1 AD. So 21 Apr 753 designates some date in the life of Charlemagne, whereas Rome's foundation date should be written 21 Apr 753 BC.
• in the Japanese calendar, we can forget the era for the Reiwa era, but we better mention it for Heisei dates, even more for Showa and more ancient eras.

This proposal is to add a new field for the option object of Intl.DateTimeFormat|.
This field eraDisplay may have the following values:

• never: the era is not displayed, whatever the value of the era field may be.
• always: the era is displayed. If necessary, the era field is set to short.
• past: the era is displayed only if the year option is defined and the era is different from the present one; or, only if the year option is defined and a (new) qualifier hidden is not present for that era in the CLDR.

The default value of this field would be past.

Note however that, if the years before the origin are on a relative scale like in the indian calendar or the iso8601 proleptic Gregorian calendar, the years are given with a "-" sign and the era remains the same: Saka era for the indian calendar, CE for the proleptic Gregorian calendar. The same holds for all islamic calendars, for the ethiopic-amete-alem and many others.

This eraDisplay option field would give a more efficient control over the era component of the date.

[littledan]

This proposal seems like a good idea to me. Thanks for the clear and detailed writeup.

I'm wondering why the logic is in place to display this era. Are there any calendars where the default should really be always rather than past? Is this simply a bug to be fixed (independent of the feature)?

@FrankYFTang you've added several Intl.DateTimeFormat features recently in the form of pull requests. Would you be interested in possibly picking this feature up?

[sffc]

We already have an era option that controls the width of the era field, so we don't need eraDisplay. However, I can't find a way to hide the era in the Coptic calendar. Maybe the era option should allow false.

The relationship between year and era is similar to the relationship between hour and dayPeriod. So, perhaps we should consider adding false as an allowable option to dayPeriod.

[aphillips]

@sffc false seems unusual. How about none instead?

[Louis-Aime]

This new value, whether false or none, does not answer the need. We must distinguish between: should we display the era of not, which is the proposed eraDisplay option; and how should we display the era, if required, which is the role of the existing era option.

If you consider the hour, you already have two options: hourCycle, which is how the hour is represented; and hour, which in the end says whether the hour should be displayed or not. Two options for one field.

Moreover, unlike all other elements in a Date string, the era part may or may not be required depending upon the date itself. It is safe to say that if the date to be displayed belongs to the same era as today (time of writing, but also time of reading), the era may be omitted; whereas if the date belongs to a past era, this era must be displayed. This is generally the case with the Japanese calendar. So it seems to me that the ICU should check whether the displayed date is in the same era as today. This should be the standard automatic mechanism.

In a few situation the writer requires the era to be displayed, because he/she wants to raise the reader's attention; or he/she considers that the era is known from the context, e.g. :

Aspasia was born in 470 BC and came to Athens in 455.

The year 455 is of course 455 BC.

However, if this option is not approved, the none value would at least make it possible that the era be not displayed when the user wishes so. Today, this seems only possible for the en-GB user.

[FrankYFTang]

I think it is a good issue we should consider to solve.
Currently, the era option has three possible value "narrow", "short", "long" and default to undefined

Looking about what @Louis-Aime concern about, I think the eraDisply option he suggest is in a different dimension as "era", because he want to control both the style (how long the era is) and the condition of showing the era.
@Louis-Aime would you willing to

1. champion a ECMA402 proposal for this (similar to dateStyle/timeStyle for you as an example)
2. join our monthly ECMA402 meeting to discuss about this

[Louis-Aime]

Thank you @FrankYFTang for considering the issue.
I am ready to champion a ECMA402 proposal for this, and to join the TC39 virtual meetings. I understand the next one is 16 to 19.11.2020 which is OK for me. Short discussions are also possible on 22nd and 23rd, during the present meeting.