Normative: Don't add default formatting to lone era

[ptomato]

Previously, if era was given by itself in the formatting options, the default formatting for the other date/time components would be added. This is inconsistent with what we do for dayPeriod where a lone dayPeriod produces formats such as "in the afternoon".

The use case of obtaining the localized era name has also been mentioned several times.

This change makes a lone era be passed to the format matcher algorithm without added date/time components, and requires implementations to have at least a year-month-day-era and year-month-era format available (which looks to be widely available across languages in CLDR.)

See: #461

[anba]

Does this require any changes in https://tc39.es/ecma402/#sec-intl.datetimeformat-internal-slots? Right now neither era nor timeZoneName are required to be present in the minimum available formats. That means for example when requesting {era: "long"}, it's valid for BasicFormatMatcher to return the format for "hour, minute" (assuming only the minimum required formats are present in the implementation.)

When given the request {era: "long"}, BasicFormatMatcher will compute the best score for:

• year, month
• month, day
• hour, minute
• dayPeriod, hour

There's a removal penalty because era is not present, and twice an addition penalty, because other fields are present. So the best score is -120 - 2*20 = -160. The formats list is unordered, so any of these four formats can be returned.

[ptomato]

I assumed no, because we also permit dayPeriod by itself but dayPeriod by itself is not part of the minimum required formats. (Although, maybe this is slightly different because dayPeriod is present with other fields.)

[anba]

(Although, maybe this is slightly different because dayPeriod is present with other fields.)

Yes, this is the important difference. Standalone dayPeriod is not required to be an available format, but at least it's guaranteed that a format is returned which includes dayPeriod when requesting standalone dayPeriod. Standalone era or standalone timeZoneName can return formats which contain neither era nor timeZoneName.

[ptomato]

Conclusion in the TG2 meeting today was:

• This should be split up into two PRs and era added separately from timeZoneName
• In both cases research should be done to check if it is likely to be web compatible
• If not web compatible, consider other options like { era: 'long', standalone: true }

[ptomato]

I've updated this to modify only era. I will open a separate PR for timeZoneName.

[sffc]

TG2 discussion on 2025-02-06: https://github.com/tc39/ecma402/blob/main/meetings/notes-2025-02-06.md#normative-dont-add-default-formatting-to-lone-era-or-timezonename-957

[sffc]

Although I would love to see this, I propose that we close this PR given that the following code has worked since Intl 1.0 and seems like a reasonable thing to write:

new Intl.DateTimeFormat("en", { era: "long" }).format(new Date())
// '6/9/2025 Anno Domini'

I think we should consider a different shape instead of redefining the current shape.

[sffc]

Era was an option in Intl 1.0:

https://402.ecma-international.org/1.0/index.html#sec-12.1.1.1

But even at that time, it was not not included in the list in question.

Same applies to timeZoneName.

[sffc]

As in #958 (comment), I'm seeking agreement on the following proposed conclusion:

We feel that the proposed behavior is better, but we are skeptical that making this change would not break the web. If we see evidence to the contrary, we can revisit. But, we are confident enough in our skepticism that we intend to close this pull request and explore other avenues for supporting standalone time zone and era formatting, which was the original motivation for the pull request.

[nciric]

I am pretty sure we didn't make a deliberate decision around the era: long that would produce the stated result.
This could be a bug in the implementation, where if none of year, month, day values are not specified we revert to some default object.

The only discussion relevant to dates was with Microsoft, which at the time couldn't support more than 5 specific skeletons. Thus the spec was left open for "implementer discretion on whether more than 5 skeletons are provided".

[sffc]

TG2 agreed to the above conclusion.

https://github.com/tc39/ecma402/blob/main/meetings/notes-2025-08-14.md#normative-dont-add-default-formatting-to-lone-era-957