[tz] Converting cities to tz identifiers (tangent)

[Guy Harris]

On Feb 20, 2018, at 6:24 PM, John Hawkinson <jhawk at MIT.EDU> wrote:

> 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).

So, for your purposes, the zone in question is the part of the zone that hasn't opted out of DST.

This means, of course, that not all cities in the XXX time zone, as defined by the US Code, can be mapped to US/XXX.

>> 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 aware that there is a backwards-compatibility alias for America/New_York named US/Eastern, and there are similar aliases with names corresponding to the names of other US time zones, but, as far as I know, that's not intended to be an indication that the file in question corresponds to "the Eastern time zone", either in the legal or colloquial sense, so anybody depending on that is depending on something not in the contract for the tzdb.

> I'm puzzled what your point is?

That the tzdb doesn't anywhere deliberately say "here's the Eastern time zone".

>>> 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)."

...which requires that you either:

	1) find a location in the Eastern time zone and map it to a tzdb region and use that

or

	2) rely on US/Eastern existing and mapping to a location in the Eastern time zone - the first of those is not part of the tzdb contract, although, in practice, if it exists, it'd be silly for it not to map to such a location (although, of course, the DST rules for "US/Eastern" will not necessarily correspond to the rules for all DST-observing places in the Eastern time zone in the future).

>> 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.

If you assume time zone/DST rule stability in the future, yeah, you could associate all cities that are in the Central time zone and that observe DST with {America/Chicago, US/Central}.

But if you assume time zone/DST rule stability in the future, you assume that no locations that are currently in America/Chicago will leave it, so you might as well use America/Chicago, as it would be no less stable than US/Central.

If, however, you don't wish to assume time zone/DST rule stability in the future, then you must assume that any static map from locations to tzdb regions may break in the future, so you must use some form of dynamic mapping and, if you cache any mappings so you don't have to do the mapping every time, you must be prepared to discard any cached mappings if any changes are made that affect some of those mappings.  In that case, again, if you're caching mappings, a mapping to US/Central is no better than a mapping to America/Chicago - if America/Chicago were to split, no matter which of the two resulting regions US/Central links to, there's probably going to be *some* city for which the cached mapping no longer applies, so you might as well use America/Chicago.  (And if you're not caching mappings, stability doesn't matter, because you'll only be using the mapping once and re-generating it every time.)

And that pertains to all of the backward/ aliases.

I.e., to go back to your original email:

> * Then I was faced with the question of what the most stable identifier to use was. For instance, take Boston, Massachusetts. I could record it as America/New_York, or as US/Eastern. For instance, at some point in the future, either Boston or New York might exit the Eastern time zone. Cases:
> 
> Case 1: If that New York exited and Boston didn't, picking US/Eastern would clearly be the more stable choice.
> 
> Case 2: And if Boston exited and New York didn't, it wouldn't matter which I chose, I'd have to update my mapping when Boston moved.
> 
> Case 3: If New York and Boston both exited US/Eastern and went the same way, then America/New_York would be the better choice.
> 
> Case 4: If New York and Boston both exited US/Eastern and did different things, it's not clear which is the better choice, but similar to Case 2.
> 
> Lather rinse repeat for 50 states + some territories and DC.
> 
> My conclusion was that in general, for most locations, the US/* ("backward") form seemed the better choice.

To decide which is the better choice for a given locale, you'd need to decide whether that locale is likely to leave the tz region it's currently in.  By "My conclusion was that in general, for most locations, the US/* ("backward") form seemed the better choice." do you mean that you looked at the locations and concluded that most of them are not likely to exit their time zone, with "their time zone" meaning "their time zone *and* choice of whether to observe DST or not"?

Furthermore, in the case of a region split, there will probably be some locales for which US/{Zonename} is the worse choice and some locales for which America/{US_City} is the worse choice, so, if you want to be prepared for a region split, you'll have to be prepared to deal with breakage no matter which one you choose - i.e., there will be locations for which the choice you make requires a change, no matter *what* choice you make.