[tz] Converting cities to tz identifiers (tangent)

[John Hawkinson]

(replies inline to 3 of Guy Harris's messages):

Guy Harris <guy at alum.mit.edu> wrote on Tue, 20 Feb 2018
at 17:06:07 -0800 in <957A2A1C-43D9-4B8D-B45A-824472015A9A at 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 at alum.mit.edu> wrote on Tue, 20 Feb 2018
at 17:23:23 -0800 in <FA109B84-3ED6-4744-B970-EC2616EAB0CB at 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 at alum.mit.edu> wrote on Tue, 20 Feb 2018
at 17:28:36 -0800 in <7A98670F-82B9-4B1C-8F0D-16C7A5E50820 at 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 at mit.edu
  John Hawkinson