javascript.builtins.Intl.supportedValuesOf('timeZone') - only partial support in Chrome

[DavidMulder0]

What type of issue is this?

Browser bug (a bug with a feature that may impact site compatibility)

What information was incorrect, unhelpful, or incomplete?

Intl.supportedValuesOf('timeZone') is incorrectly implemented in Chrome since at least 2022 missing Etc/* zones.

What browsers does this problem apply to, if applicable?

Chromium (Chrome, Edge 79+, Opera, Samsung Internet)

What did you expect to see?

Chrome seems to leave out the 'etcetera' source file, meaning time zones such as UTC are completely missing. If I am reading the spec correctly ( https://tc39.es/ecma402/#sup-availablenamedtimezoneidentifiers ) it seems that it should be included.

Did you test this? If so, how?

e.g. Intl.supportedValuesOf("timeZone").includes('UTC') return true in both Firefox and Safari, but false in Chrome.

Can you link to any release notes, bugs, pull requests, or MDN pages related to this?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/supportedValuesOf#supported_time_zone_identifiers

Do you have anything more you want to share?

No response

MDN URL

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/supportedValuesOf

MDN metadata

MDN page report details

• Query: javascript.builtins.Intl.supportedValuesOf
• Report started: 2025-01-31T15:22:17.407Z

[DavidMulder0]

If this should only be documented in the text of the MDN article instead of in the compatibility data then let me know, happy to learn.

[DavidMulder0]

And just to elaborate, the problem isn't limited to just the etc zone I believe. Intl.DateTimeFormat supports both Europe/Kyiv and Europe/Kiev as is expected if I read the spec correctly, but according to the spec only the primary name should be returned, as they are both in the same country. The MDN article even explictly has an example of this stating that Asia/Kolkata should be included, whilst Asia/Calcutta shouldn't be, which is the case in Firefox and Safari, but not in Chrome.

[Josh-Cena]

Intl.DateTimeFormat supports both Europe/Kyiv and Europe/Kiev as is expected if I read the spec correctly, but according to the spec only the primary name should be returned, as they are both in the same country.

It says the following:

As you browse the list, note that the standardization of Temporal requires browsers to always return the primary identifier in the IANA database, which may change over time. See time zones and offsets for more information.

And you need to go to the linked doc, which says:

As a result, some browsers like Chrome and Safari reported CLDR's outdated identifiers, while other browsers like Firefox overrode CLDR's defaults and reported the up-to-date primary identifiers.

Therefore, Chrome and Safari both have always reported outdated identifiers, and this behavior has only been standardized with the introduction of Temporal. Until they implement Temporal, their handling of time zone identifiers is not up to date with the latest requirements. It might be worth documenting in BCD when they start canonicalizing identifiers to the new version, though even without a BCD change you could infer this information based on when they start introducing Temporal.

As for your other report about Etc/* time zones and UTC, I do believe that the spec defines a precise list of identifiers to be returned, and explicitly says that UTC must be contained, so it seems there are some compliance issues here.

[Josh-Cena]

Relevant bugs:

• https://issues.chromium.org/issues/42203023
• https://issues.chromium.org/issues/42203303

I didn't find anything related in WebKit; perhaps one should be filed.