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" }

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.

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

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.

This is the same behavior as Bug 1752253.

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

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

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.

Thanks, marking 98 as wontfix then.

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.