I am using JavaScript Intl API to detect the user's timezone in the browser:

Intl.DateTimeFormat().resolvedOptions().timeZone

While this API looks stable, I don't know what to do with the next. On my Windows 10 machine, the timezone is set to US Eastern Standard Time:

C:\> tzutil /g
US Eastern Standard Time

In Firefox and Edge the above JavaScript code results with "America/Indiana/Indianapolis", while Chrome returns just "America/Indianapolis".

Why this yields different results in different browsers? Is it a Chrome bug or should I transform the time zones somehow before processing them on the server?

On Ubuntu (which is my server's OS), if I list available time zones with timedatectl list-timezones, there is "America/Indiana/Indianapolis", but there is no "America/Indianapolis". Because of this issue I cannot accept Chrome's "America/Indianapolis" from the client, as I grab the "available time zones list" from the output of timedatectl list-timezones. Which behavior should I apply here?

Any help is appreciated. Thank you!

I am using JavaScript Intl API to detect the user's timezone in the browser:

Intl.DateTimeFormat().resolvedOptions().timeZone

While this API looks stable, I don't know what to do with the next. On my Windows 10 machine, the timezone is set to US Eastern Standard Time:

C:\> tzutil /g
US Eastern Standard Time

In Firefox and Edge the above JavaScript code results with "America/Indiana/Indianapolis", while Chrome returns just "America/Indianapolis".

Why this yields different results in different browsers? Is it a Chrome bug or should I transform the time zones somehow before processing them on the server?

On Ubuntu (which is my server's OS), if I list available time zones with timedatectl list-timezones, there is "America/Indiana/Indianapolis", but there is no "America/Indianapolis". Because of this issue I cannot accept Chrome's "America/Indianapolis" from the client, as I grab the "available time zones list" from the output of timedatectl list-timezones. Which behavior should I apply here?

Any help is appreciated. Thank you!

• javascript
• google-chrome
• date
• datetime
• timezone

• 1 Actually, both are the same - check their names in this list (one is a link to another). Check also here – user7605325 Commented Aug 24, 2017 at 17:40
• unix.stackexchange./questions/35781/… – Josh Lee Commented Aug 24, 2017 at 17:44
• @Hugo, thank you. Does the "backward" file you linked provide the plete list of "time zone aliases"? What should be the algorithm? Looks like if I have LINK-NAME with the exact timezone name, I need to change it to TARGET in that table. Is this correct? Could you answer a question then? – nikitaeverywhere Commented Aug 24, 2017 at 17:46
• This file is maintained by IANA (which is used by lots of applications and languages) and it's probably the most plete we can have. Regarding "what should be the algorithm?", it depends on how your applications deal with timezones. In Java, for example, both names work and are equivalent. Not sure how browsers and JavaScript wil handle both names, but probably using America/Indiana/Indianapolis is better as it's the most recent name. Not sure why Chrome still uses the old one – user7605325 Commented Aug 24, 2017 at 17:54

3 Answers 3

Chrome, like many others, gets its time zone information through ICU, which in turn sources from CLDR, which in part sources from IANA.

There is a subtle difference between IANA and CLDR with regard to canonicalization.

• IANA treats the preferred form of the time zone identifier as canonical. If the preferred form changes, they make the new one primary (a Zone entry) and move the old one to an alias (a Link entry).

• CLDR treates the first form of the time zone identifier as canonical. That is, the first time it appeared in CLDR, it is locked in forever. If a new form ever appears, it is added as an alias in the /mon/bcp47/timezone.xml file.

Taking your case of Indianapolis:

• IANA Zone entry (reference here)

  Zone    America/Indiana/Indianapolis    ...
  

• IANA Link entry (reference here)

  Link    America/Indiana/Indianapolis    America/Indianapolis
  

• In CLDR, the primary zone is listed first in the "aliases" attribute, followed by other aliases. (reference here)

  <type name="usind" description="Indianapolis, United States" alias="America/Indianapolis America/Fort_Wayne America/Indiana/Indianapolis US/East-Indiana"/>
  

The same thing can be found with Asia/Calcutta vs. Asia/Kolkata and several other examples.

Additionally, be aware that the Windows time zone mappings also source from CLDR, in the /mon/supplemental/windowsZones.xml file. You'll notice there that US Eastern Standard Time is mapped to America/Indianapolis. So the difference between browsers depends very much on which canonicalization rules are followed.

In the end, it doesn't really matter which alias is used. They point at the same data.

Also worth pointing out, that particular Windows zone should only be selected if you care about historical time changes in Indiana. If you are just in the US Eastern time zone, you should set your system to "Eastern Standard Time", rather than "US Eastern Standard Time". (Yes, those IDs are confusing...)

zone.tab is inplete. Some time zones are represented as symbolic links:

$ find /usr/share/zoneinfo/America -name Indianapolis -exec file {} \;
/usr/share/zoneinfo/America/Indiana/Indianapolis: symbolic link to ../Indianapolis
/usr/share/zoneinfo/America/Indianapolis: timezone data, version 2, 7 gmt time flags, 7 std time flags, no leap seconds, 99 transition times, 7 abbreviation chars

I'm not sure how/why each browser returns a different result (probably they read from different sources and/or it can be due to how each implements Intl.DateTimeFormat). But it doesn't matter, because both are the same timezone.

If you check this list, you'll see that America/Indianapolis links to America/Indiana/Indianapolis. Those names in the format Region/City are maintained by IANA and it's probably one of the best sources we have about timezone information.

IANA also keeps a backward file that maps those 2 names, with America/Indiana/Indianapolis being the most recent one.

So one alternative is to get a copy of the backward file and use it to map whatever name you receive to the respective new name, and also validate against your server's timezone list.