(replies inline to 3 of Guy Harris's messages): Guy Harris <guy@alum.mit.edu> wrote on Tue, 20 Feb 2018 at 17:06:07 -0800 in <957A2A1C-43D9-4B8D-B45A-824472015A9A@alum.mit.edu>:
I think it generally means the region as defined in 15 USC 260a et seq.
There is no tz region that could handle the US Mountain time zone, however, because Arizona, which is in the Mountain time zone, does not observe DST, and Colorado, which is also in the Mountain time zone, does observe DST.
I would assert that, for colloquial purposes at least, Arizona is not part of the US Mountain time zone, because it elects not to follow DST, even though it would otherwise be so considered, regionally or boundary-wise (or within the meaning of 15 USC §261) (This is more apparent when reviewing 49 CFR 71, which, by regulation, codifies the boundaries of hte zones).
There's also a tzdb id "EST" which is 5 hours retarded from UTC all year around and a tzdb id "EST5EDT" which is "5 hours retarded from
Red herring.
In what way does asking for "the US Eastern time zone" get you America/New_York in the tz project? What part of the tz database tie America/New_York, and no other tz region, to "the US Eastern time zone"?
The "backward" file. But since you know this, I'm puzzled what your point is? pb3:tz jhawk$ grep US/Eastern backward Link America/New_York US/Eastern
Sure it does. The answer is just more approximate than some people (you?) might like, but is perfectly fine for others' purposes (mine own).
So what is this mechanism?
Eh? As you said yourself: "You can ask about the current un-adjusted UTC offset for a given location in the Eastern time zone (which might be different from the un-adjusted UTC offset for that location in the past, as per the above information for Indianapolis)." I feel as if I'm talking past you, though? Guy Harris <guy@alum.mit.edu> wrote on Tue, 20 Feb 2018 at 17:23:23 -0800 in <FA109B84-3ED6-4744-B970-EC2616EAB0CB@alum.mit.edu>:
But what happens if somebody decides to schedule a meeting in "Mountain time" some time between 2 o’clock antemeridian on the second Sunday of March and 2 o’clock antemeridian on the first Sunday of November? That wouldn't suffice; you'd either have to explicitly schedule it for "Mountain standard time" or "Mountain daylight time", or treat it as implied that Arizona doesn't count and "Mountain time" is "Mountain daylight time" during that period.
Yes. You treat it that Arizona doesn't count as "Mountain time." It has it's own rule set.
"The US Eastern time zone" doesn't inherently map to any particular tzdb region. It could be mapped to the tzdb region that's 1) currently in that time zone, 2) has been outside that region for the shortest period of time (including "it's been there ever since standard time was established") and 3) covers the largest area, or population, amongst regions that match on the first two criteria.
I think, essentially, (1) and (3) are the same. The "US Eastern time zone" is coterminus with the America/New_York boundary (I think). A more interesting case:
That would map it to America/New_York, and "the US Central time zone" would map to America/Chicago,
Here, the "US Central time zone" is not coterminus with America/Chicago, since the America/Chicago boundary excludes southeast Indiana (and various other things), because of history. So, yes, "US Central time zone" isn't the same as US/Central (which is America/Chicago) because of such historical issues. But is this is problem or concern? Not for most users, and not for people scheduling things in the future.
...and the ones in backward/ don't necessarily correspond to the *entire* zone with the name; US/Mountain doesn't apply to Mountain time in Arizona, for example.
This is all true, but I am somewhat of a loss as to why this is an interesting fact to highlight in this discussion? Maybe I'm guilty of monopolizing the thread and focusing on the part I raised and the thread has moved on, though? Guy Harris <guy@alum.mit.edu> wrote on Tue, 20 Feb 2018 at 17:28:36 -0800 in <7A98670F-82B9-4B1C-8F0D-16C7A5E50820@alum.mit.edu> (quoting Steve Allen):
I think a US lawyer would disagree that there is any fuzziness for the "time zone" US/Eastern *if* that were defined as in 15USC260 thru 15USC263. The Uniform Time Act of 1966
...unless some State decides to exempt itself as, for example, the Grand Canyon State currently does. Some parts of the Mountain time zone change local times in that fashion (as modified by subsequent laws, so no longer April and October), other parts do not.
Well, that exemption is permitted pursuant to 15 USC §260a(a)(1). Of course, if we want to be pedantic, Steve was only talking about US/Eastern, where there currently are not such exemptions. But if we extend his comment to refer to the western zones, then yes, there's a bit of fuzziness. Not for the lawyers, but for the rest of us. The lawyers would disagree on fuzziness within the meaning of the statute -- there the plain language is clear that states that opt out of DST are still within their statutory time zones -- but rather the rules we follow are different. That is, Arizona doesn't follow the US/Mountain rules, it follows the US/Arizona (or America/Phoenix, if you must). So when someone says "mountain time," the fuzziness is whether they are including Arizona or not. Colloquially, I'd say we generally think they're not. (So, sure, my comment of 18:23:14 Eastern (see that?) where I said "generally [as] 15 USC 260a et seq" was insufficiently precise to address your concern. Perhaps I should have chosen a wiggle-word more wiggly than "generally," on the assumption you meant a region/zone more complicated than Eastern). But I don't see what this has to do with the questions raised of how to one maps states to zones and whether to use US/* -style "backward" names or not. I mapped Arizona to US/Arizona, not US/Mountain, and it solved my problems. One could quibble about whether a state to tz mapping there should go to US/Mountain or America/Phoenix, but I'm not sure I see why we'd quibble about anything else. --jhawk@mit.edu John Hawkinson