Intl.DateTimeFormat.prototype.formatToParts ( date ) using eraDisplay - patterns or last time deletion ?

[Louis-Aime]

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.

[sffc]

CC @FrankYFTang

In my opinion, we should just add both the era and non-era patterns as slots in the Intl.DateTimeFormat, similar to how we are doing the Temporal slots. In practice, implementations can leave those slots uninitialized until they are needed.

[sffc]

This was discussed at TG2: https://github.com/tc39/ecma402/blob/master/meetings/notes-2022-04-21.md#intldatetimeformatprototypeformattoparts--date--using-eradisplay---patterns-or-last-time-deletion

Conclusion: Use internal slots. Try to make the mechanism consistent with Temporal once one or the other proposal is merged.

[sffc]

This is in the Stage 2 proposal.