Intl.supportedValuesOf('timeZone') for UTC, Etc/GMT*, and other non-contintent/non-ocean time zone identifiers

[justingrant]

As part of work on proposal-canonical-tz, I noticed that JS engines have very different results from Intl.supportedValuesOf('timeZone') for time zones that are not associated with a continent or ocean.

V8 does not return any of these zones. Safari returns only one: UTC. Firefox returns 40 zones, including "UTC", Etc/ zones like "Etc/GMT+11", and a few others like "EST" and "CET".

Should the 402 spec be more prescriptive about what kinds of canonical time zone identifiers should vs. should not be returned by this API?

Intl.supportedValuesOf('timeZone').filter(z => !['Asia', 'Africa', 'Europe', 'Australia', 'America', 'Antarctica', 'Atlantic', 'Pacific', 'Indian', 'Arctic'].some(c => z.startsWith(c)))

// => Chrome: []
// => Safari: ["UTC"]
// => Firefox: [
  "CET",
  "CST6CDT",
  "EET",
  "EST",
  "EST5EDT",
  "Etc/GMT+1",
  "Etc/GMT+10",
  "Etc/GMT+11",
  "Etc/GMT+12",
  "Etc/GMT+2",
  "Etc/GMT+3",
  "Etc/GMT+4",
  "Etc/GMT+5",
  "Etc/GMT+6",
  "Etc/GMT+7",
  "Etc/GMT+8",
  "Etc/GMT+9",
  "Etc/GMT-1",
  "Etc/GMT-10",
  "Etc/GMT-11",
  "Etc/GMT-12",
  "Etc/GMT-13",
  "Etc/GMT-14",
  "Etc/GMT-2",
  "Etc/GMT-3",
  "Etc/GMT-4",
  "Etc/GMT-5",
  "Etc/GMT-6",
  "Etc/GMT-7",
  "Etc/GMT-8",
  "Etc/GMT-9",
  "Factory",
  "HST",
  "MET",
  "MST",
  "MST7MDT",
  "PST8PDT",
  "UTC",
  "WET"
]

[sffc]

TG2 discussion: https://github.com/tc39/ecma402/blob/master/meetings/notes-2023-05-04.md#intlsupportedvaluesoftimezone-for-utc-etcgmt-and-other-non-contintentnon-ocean-time-zone-identifiers-778

[anba]

Intl.supportedValuesOf calls AvailableCanonicalTimeZones, which computes the result based on all supported time zone and link names.

• CET, EET, MET, and WET are defined time zone zones in the europe file.
• CST6CDT, EST, EST5EDT, HST, MST, MST7MDT, and PST8PDT are defined as time zone zones in the northamerica file.
• Etc/GMT-14 to Etc/GMT+12 are defined as time zone zones in the etcetera file.
• Etc/UTC and Etc/GMT are also defined in the etcetera file. Both are canonicalised to UTC in CanonicalizeTimeZoneName.
• Factory is from the factory file. IIRC it's just a placeholder time zone, but because it's supported in all browsers (new Intl.DateTimeFormat("en", {timeZone: "Factory"}).resolvedOptions().timeZone), I've never removed the support for it.

So all additional time zones returned by Firefox are correct and should also be returned by the other browsers, as long as the time zone id is supported by Intl.DateTimeFormat.

[anba]

Previous discussions and bug reports:

• Intl.supportedValuesOf('timeZone') and UTC proposal-intl-enumeration#47
• Intl.supportedValuesOf('timeZone') not containing complete data nodejs/node#43678
• https://bugs.chromium.org/p/v8/issues/detail?id=13084

[sffc]

In the latest TZDB, thanks to @justingrant, the legacy zones like "WET" are now links in backward.

I think that should make this issue easier to resolve, now? Etc/* zones should be included in supportedValuesOf.

I think we should go ahead and make a PR.

[justingrant]

I think we should go ahead and make a PR.

AFAIK, no PR for the ECMA 402 spec is needed. But JSC and V8 don't currently follow the current spec because they omit Etc/* (both JSC and V8) zones and omit (V8 only) UTC.

So changing this is really a matter of convincing implementers to follow the spec.

[justingrant]

On the other hand, if we want to reify the no-Etc behavior of V8/JSC into the spec, that would require a normative PR.

Should we discuss this at the next TG2 meeting?

[sffc]

I think impls should return Etc/* time zones in supportedValuesOf, and not WET/CST/...

Is this what the spec currently requires? If so, then maybe we only need to add some tests.

[justingrant]

Is this what the spec currently requires?

Yes. There is no filtering out of Etc/* and UTC in the spec. All primary time zone identifiers are supposed to be returned, but today only SpiderMonkey is following the spec.