7

I am trying to convert timestamp in to various time zone's local time and found certain TimeZone are not supporting in Chrome (v76.0.38) but working fine in Mozilla (v68.0.2).

  let d = new Date(1567083463);
  let n = d.toLocaleString('en-GB', { timeZone: "US/Arizona" });

Uncaught RangeError: Invalid time zone specified: US/Arizona

at Date.toLocaleString ()

Several other timezones are also throwing the same error

US/Alaska US/Mountain US/Central US/East-Indiana

These timezones are officially supported as mentioned in their website Chrome Supported Time Zone Values

Community
  • 1
  • 1
kiran goud
  • 803
  • 2
  • 10
  • 17

1 Answers1

19

That page describes timezones supported by another google product, not Chrome.

Referring to MDN's documentation on toLocaleString:

timeZone
The time zone to use. The only value implementations must recognize is "UTC"; the default is the runtime's default time zone. Implementations may also recognize the time zone names of the IANA time zone database, such as "Asia/Shanghai", "Asia/Kolkata", "America/New_York".

Valid time zones can be found at that IANA link, or you can use Wikipedia: List of tz database time zones. You'll notice that all of the "US/*" timezones are deprecated. Use only Canonical entries from the Wikipedia page, such as:

  • America/New_York
  • America/Denver
  • America/Chicago

etc.

  • 1
    They are deprecated from the perspective that there is a prefered newer form. But even this is opinionated (I was actually the one to add that column to the Wikipedia page). They should all still work. There's something else going on here, as *some* of the older "deprecated" style still work in Chrome and others do not. A few examples, `"Canada/Pacific"`, `"Australia/Queensland"`, `"Mexico/General"`, and `"Iran"` work in Chrome, but `"Australia/ACT"`, `"Mexico/BajaNorte"`, and `"GB-Eire"` do not. – Matt Johnson-Pint Aug 29 '19 at 20:45
  • 1
    @MattJohnson-Pint Because `"Mexico/BajaNorte"` and others are the *old* names for regions, and they've been deprecated by the IANA. http://ftp.iana.org/tz/tzdb-2016g/backward . Wikipedia shouldn't be taken as the canonical source, only a convenient lookup. Ultimately the IANA data should be consulted. –  Aug 29 '19 at 20:58
  • @MattJohnson-Pint As well, the spec only says that UTC must be supported; it makes no mention of any other time zones, or lists thereof, being supported. Ultimately its up to individual implementations. Still, I wouldn't expect a TZ that has been deprecated by the IANA to work. –  Aug 29 '19 at 21:05
  • Thanks I have changed the names but its confusing to see it working properly in Mozilla not in chrome – kiran goud Aug 30 '19 at 12:48
  • 1
    The spec does not specify what times zones should be supported. It is left up to individual implementations. –  Aug 30 '19 at 13:03
  • Actually, EMCA 402, 6th edition, section 6.4 "Time Zone Names" says: "All registered Zone and Link names are allowed. Implementations must recognize all such names...". Thus, it seems Chromium is not currently following the spec. – Matt Johnson-Pint Mar 30 '20 at 20:49
  • Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=364374 – Matt Johnson-Pint Mar 30 '20 at 20:56
  • For what it's worth, I've had "US/Mountain" in my app and it worked fine on iOS, Samsung, Huawei and some other devices, but not on Pixel 2 – Nikola Dragić Oct 23 '20 at 15:46