1751833 - month: 'numeric' option ignored by Intl.DateTimeFormat constructor using Hebrew calendar

Status: REOPENED

(Core :: JavaScript: Internationalization API, defect, P3)

Description

[Justin Grant]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:97.0) Gecko/20100101 Firefox/97.0

Steps to reproduce:

dtf = new Intl.DateTimeFormat(`en-US-u-ca-hebrew`, {
  day: 'numeric',
  month: 'numeric',
  year: 'numeric',
  era: 'short',
  timeZone: 'UTC'
});
parts = dtf.formatToParts(new Date('2019-02-06T00:00Z'));
parts.filter(p => p.type === 'month')[0];

Actual results:

{ type: "month", value: "Adar I" }

Intl.DateTimeFormat, in the Hebrew calendar only, is ignoring the month: 'numeric' option passed into the constructor and is instead formatting the month as if the month: 'long' option were used.

This change (from FF 95=>96) broke the Temporal polyfill which relies on the output of DateTimeFormat#formatToParts. See https://github.com/tc39/proposal-temporal/issues/2015 for more context.

Expected results:

The same output as FF 95, latest Chrome 97.0.4692.99, and latest Safari 15.2 (17612.3.6.1.6):

{ type: "month", value: "6" }

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Internationalization' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=511af4b42efc6143819739c499a83d5ba4d5e41a&tochange=a1b606f473a01b035eee56e271d02467b27a458b

Comment 3

[Greg Tatum [:gregtatum] (REO Fx132)]

The components bag generates the skeleton: "GyMd"
CLDR says that this should translate to: "d MMM y GGGGG"
This was changed in v40 of the CLDR data.

It looks like Chrome Canary behaves the same here, which mostly likely is running off of the same CLDR data.

I believe this is not a bug, as the translator decision should override the developer decision from the components bag. If this is not correct, then I believe the proper place to fix this is in the CLDR translations.

Let me know Justin if you disagree with the analysis.

Comment 4

[Greg Tatum [:gregtatum] (REO Fx132)]

This is the same behavior as Bug 1752253.

Comment 5

[Greg Tatum [:gregtatum] (REO Fx132)]

I'm going to tentatively re-open, since Bug 1752253 has the same issue, and looks like a bug.

Comment 6

[Pascal Chevrel:pascalc]

Greg, you marked that as an S4, can you confirm that it has low to no impact to users and we can mark it as wontfix for 98? thanks

Comment 7

[Greg Tatum [:gregtatum] (REO Fx132)]

Yes, this is low impact for users.

The fix here is to upstream the error to CLDR, or to create a custom tailoring of our locale data to fix it. I don't know that we have the custom tailoring already built in to the CLDR update code, but I haven't investigated further.

Comment 8

[Pascal Chevrel:pascalc]

Thanks, marking 98 as wontfix then.

Comment 9

[Greg Tatum [:gregtatum] (REO Fx132)]

I'm unassigning myself from this, as I'm not actively working on it. I can circle back to confirm the fix when CLDR-15510 is addressed.