Why So Many IANA Time Zones Names?

Question

Javascript allows you to see what time it is in another timezone if you specify the IANA given name of that timezone. For example:

let strTime = new Date().toLocaleString("en-US", {timeZone: "America/Chicago"});
console.log(strTime);

Below you can see that IANA provides multiple names within each general timezone:

America/New_York    Eastern (most areas)
America/Detroit Eastern - MI (most areas)
America/Kentucky/Louisville Eastern - KY (Louisville area)
America/Kentucky/Monticello Eastern - KY (Wayne)
America/Indiana/Indianapolis    Eastern - IN (most areas)
America/Indiana/Vincennes   Eastern - IN (Da, Du, K, Mn)
America/Indiana/Winamac Eastern - IN (Pulaski)
America/Indiana/Marengo Eastern - IN (Crawford)
America/Indiana/Petersburg  Eastern - IN (Pike)
America/Indiana/Vevay   Eastern - IN (Switzerland)
America/Chicago Central (most areas)
America/Indiana/Tell_City   Central - IN (Perry)
America/Indiana/Knox    Central - IN (Starke)
America/Menominee   Central - MI (Wisconsin border)
America/North_Dakota/Center Central - ND (Oliver)
America/North_Dakota/New_Salem  Central - ND (Morton rural)
America/North_Dakota/Beulah Central - ND (Mercer)
America/Denver  Mountain (most areas)
America/Boise   Mountain - ID (south); OR (east)
America/Phoenix MST - Arizona (except Navajo)
America/Los_Angeles Pacific
America/Anchorage   Alaska (most areas)
America/Juneau  Alaska - Juneau area
America/Sitka   Alaska - Sitka area
America/Metlakatla  Alaska - Annette Island
America/Yakutat Alaska - Yakutat
America/Nome    Alaska (west)
America/Adak    Aleutian Islands
Pacific/Honolulu    Hawaii

Why is that necessary?

For example, both America/Detroit and America/New_York are (generally) in the Eastern Time Zone. Why don't these two locations share a single IANA timezone name?

Are there occations of the year where the time in New York is different from that of Detroit?

If not, then why allow more timezone names than the exact number of variances?

Zygophyte

"Each main entry in the database represents a timezone for a set of civil-time clocks that have all agreed since 1970. Timezones are typically identified by continent or ocean and then by the name of the largest city within the region containing the clocks..." Source: IANA -> Sources for time zone and daylight saving time data – Nomenclature

Can I safely assume that all the different IANA names in a given timezone will act exactly the same in respect to daylight savings time? – Zygophyte

There may have been historical differences between some of these timezones and/or still existing differences wrt. DST and/or there may again exist differences in the future. I'm not sure this is entirely down to convenience. – Muscular

@marekful - The names do not refer just to offsets, but rather the complete set of offsets, transition dates/times, and abbreviations that a particular region's civil time has gone through. Also, one can't necessarily pick the closest city, but rather one has to know which city aligns with the same local time. Consider a city near a geopolitical border may align with the time of a city much further inland, rather than the city just across the border. – Accountant

@LonnieBest - No, you can't safely assume that. You have to treat each entry as a unique entity. If you want to know when they align and when they differ, then you either have to example the sources, or write code to hunt for the differences. There are also web sites like timeanddate.com that can help make it easier to dig in to the details. – Accountant

It's not even slightly down to convenience. People often ask why their favorite city does not have its own zone, and the answer is that it would not contain different data than (not the user's favorite city). – Chowchow

Answer 1

I'll use your example:

For example, both America/Detroit and America/New_York are in the Eastern Time Zone. Why don't these two locations share a single timezone name?

In the TZDB, the Zone entry for America/New_York looks like this:

# Zone  NAME              GMTOFF    RULES   FORMAT   [UNTIL]
Zone    America/New_York  -4:56:02  -       LMT      1883 Nov 18 12:03:58
                          -5:00     US      E%sT     1920
                          -5:00     NYC     E%sT     1942
                          -5:00     US      E%sT     1946
                          -5:00     NYC     E%sT     1967
                          -5:00     US      E%sT

While the Zone entry for America/Detroit looks like this:

# Zone  NAME              GMTOFF    RULES   FORMAT   [UNTIL]
Zone    America/Detroit   -5:32:11  -       LMT      1905
                          -6:00     -       CST      1915 May 15  2:00
                          -5:00     -       EST      1942
                          -5:00     US      E%sT     1946
                          -5:00     Detroit E%sT     1973
                          -5:00     US      E%sT     1975
                          -5:00     -       EST      1975 Apr 27  2:00
                          -5:00     US      E%sT

To fully decipher this, one also needs the Rule entries for US, NYC, and Detroit (which I won't copy/paste here, but you can follow the links).

As you can see, Detroit has had variations from New York, the last of which was in 1975 when Detroit started daylight saving time slightly later than most of the Eastern time zone (Apr 27 shown here vs Feb 23rd given by Rule US).

Since then however, they have been the same. The TZDB rules require a unique zone for areas that have agreed since 1970, and these areas have deviations in 1973 and 1975, thus they require unique zone identifiers.

One can see this difference in JavaScript like so:

var d = new Date("1975-03-01T00:00:00.000Z"); // Midnight UTC on March 1st
d.toLocaleString("en-US", {timeZone: "America/New_York"})  //=> "2/28/1975, 8:00:00 PM"
d.toLocaleString("en-US", {timeZone: "America/Detroit"})   //=> "2/28/1975, 7:00:00 PM"

Of course, if in your application, you never deal with dates going back that far, then you can just use America/New_York to represent the US Eastern time zone, and omit America/Detroit (and a few others) - but this is entirely your decision to make.

You may also be interested in reading the Theory file with in the tzdb itself, which explains the concepts and principles of the time zone database in a lot more detail.

Accountant

Side note: I found that a couple of official timezones were missing support in Chromium 71, I reported it here. – Zygophyte