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-gregory`, {
  day: 'numeric',
  month: 'numeric',
  year: 'numeric',
  era: 'short',
  timeZone: 'UTC'
});
parts = dtf.formatToParts(new Date('2019-02-06T00:00Z'));
parts.filter(p => p.type === 'era')[0];

Actual results:

{ type: "era", value: "A" }

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/2020 for more context.

I assume this is related to bug 1751833.

Expected results:

{ type: "era", value: "AD" }

The output above is what FF 95, latest Chrome 97.0.4692.99, latest Safari 15.2 (17612.3.6.1.6), and (see excerpt below) the MDN docs say should be emitted:

<dt><code>era</code></dt>
  <dd>The representation of the era. Possible values are:
  <ul>
   <li>"<code>long</code>" (e.g., <code>Anno Domini</code>)</li>
   <li>"<code>short</code>" (e.g., <code>AD</code>)</li>
   <li>"<code>narrow</code>" (e.g., <code>A</code>)</li>
  </ul>
  </dd>

This feels like the CLDR data is wrong... This is the same thing as Bug 1751833.

https://github.com/unicode-org/cldr-json/blame/83f6144d8aa3d10e932c25924d4c903925b24257/cldr-json/cldr-dates-modern/main/es-US/ca-gregorian.json#L347

What's weird here is that Chrome v100 is not agreeing with us, even though it is with Bug 1751833.

Justin, do you have thoughts here?

I agree that the CLDR data looks wrong. "A" is the correct value for the era: 'narrow' option. Looks like a typo to use it also for era: 'short'.

Not sure why Chrome isn't agreeing, perhaps because they're patching this obvious bug in the source data, but didn't catch the subtler issue in Bug 1751833?

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

Just ran into this as well. Looks like both Safari and Chrome return AD/BC rather than A/B for the short style.

What I don't understand is why Chrome and Safari get different results, don't they also use ICU? Andre is this something you know?

This is actually exploiting an ICU bug, but ensures we return the same results
as other browsers. When the ICU bug has been fixed, we can revert this back to
"G".

(In reply to Tom Schuster [:evilpie] from comment #7)

What I don't understand is why Chrome and Safari get different results, don't they also use ICU? Andre is this something you know?

I tracked this down to this ICU bug https://unicode-org.atlassian.net/browse/ICU-22138. When we change the era skeleton from "G" to "GGG", the expected output is produced.

https://hg.mozilla.org/mozilla-central/rev/21386acd4473

This reverts commit 47452bdfab077e1f686d4321c658824f5599c533.

Reproduced this issue on an affected Nightly build from 2022-01-24 (20220124093541), on macOS 10.15
Verified fixed on Firefox 106.0 (20221010110315) on macOS 10.15.