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.

[caugner]

Reproduced with this Playground. Both Firefox 136 and Safari 18.3 return ["UTC"], whereas Chrome 132 returns [].

How about we add subfeatures for all the 6 categories, and mention this limitation as part of Chrome support for timeZone? I don't think this limitation is severe enough to be considered a partial implementation though.

[DavidMulder0]

@caugner You guys absolutely know better than I do, so I will just give my external 2ct: the reason I would love to see it marked as partial support is because that would save a future developer a lot of time if they instantly see at a top of the corresponding MDN/caniuse page that they can't just use the API to populate a dropdown with timezones, which I would guess is the main real life usecase of this API. Like at the end of the day anytime APIs are inconsistent in a big way across browsers (especially in sneaky unexpected ways) there is no warning big enough. And sure, if this was some obscure timezone then maybe I would still be like 🤷, but UTC is kind of the most important of them all by definition 😅 .

Anyhow: Also an obligatory: Thank you guys for the work you do on this project, it's been incredibly useful!

[Josh-Cena]

Like at the end of the day anytime APIs are inconsistent in a big way across browsers (especially in sneaky unexpected ways) there is no warning big enough.

Other Intl.supportedValuesOf options, notably currency, are inconsistent too. This part of variation is by design.

Also, I would strongly advise against ever displaying "UTC" as a choice to your user, or displaying any time in UTC. It's an exchange format and not a user-facing format.

However, I currently believe that, per my spec reading, V8 not including "UTC" is a spec deviation and should be called a bug. Whether it's partial implementation or just an implementation note is up to the maintainers' discretion.

[DavidMulder0]

@Josh-Cena Our context: Select a timezone for static content to be published. If the content in question is specific to a region they will likely use a timezone for that region, but for 'global' content we would expect many customers to select UTC. Also: I know of at least one company that internally uses UTC for much of its communication.

---

And yeah, 'variation by design' and 'one of the main source files of timezones from the IANA time zone database missing' are frankly completely different things.