[tz] Converting cities to tz identifiers (tangent)

[John Hawkinson]

Guy Harris <guy at alum.mit.edu> wrote on Tue, 20 Feb 2018
at 19:53:07 -0800 in <B46E0D0E-6484-4F09-A89C-E0957783FDE3 at alum.mit.edu>:

> 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 think it's intended to be an indication in the colloquial sense, and that people like me would complain loudly if a future update decided to break this.

> ...which requires that you either:
...
> 	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).

I'm pretty comfortable with this assumption.


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

"You could do A, but you might as well do B" is not a compelling argument for doing B over A.

And furthermore:

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

I'm not quite sure how we're distinguishing static mapping from dynamic mapping.
If by "dynamic mapping" you mean "I update my static mapping file," then sure.


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

No, these events do not have equal probabilities.
For the cities I care about, my conclusion is that the current lead city of the time zone ("backward" link) is more likely to exit the zone than the city I am mapping from.  Or put differently, Boston is more likely to disassociate from New York than it is to disassociate with Eastern time. (But, it turns out, neither of those are the likely case, standing alone. Most likely none of those will happen, but also, if one happens the other is likely to happen too.)

An additional point we haven't discussed, but happens to matter to me, is that this mapping list is likely to be looked at by people who aren't familiar with the tz database, and for whom seeing that Boston is associated with US/Eastern is more meaningful and less confusing than seeing Boston is associated with America/New_York. I realize this is a problem the tz database generally tries to pretend to ignore, in the name of politics, and that the US/* formations are specially privileged because most countries don't get that non-city-specific choice (but the US does. How convenient for those of us there.) But it's a realistic consideration for me. I'm not sure why I omitted it from my initial reasoning -- perhaps I managed to bury it subconsciously.

> 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"?

Almost. You frame this in absolute probabilities, but the probabilities are all low. I frame this in relative probabilities between 2 events.

I concluded that the cities are more likely to diverge from the lead cities of their zone (Boston from New York) than they are to exit their «zone and choice of DST» (as you put it).

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

Agreed. The calculus for me was which was the more likely case, but I did not mean to suggest anyone could rely on such things with any certainty.

When the rules change, everybody has to pay attention.


As I write this, Paul pointed out an error of mine:

> Not really: even inside the US, the US Eastern time zone currently
> also includes America/Indiana/Indianapolis, America/Indiana/Marengo,
> America/Indiana/Vincennes, America/Indiana/Petersburg,
> America/Indiana/Winamac, America/Indiana/Vevay,
> America/Kentucky/Louisville, America/Kentucky/Monticello, and
> America/Detroit. And several locations outside the US are currently
> in the same time zone, e.g., America/Nassau.


Whoops, Somehow I managed to convince myself that those Indiana and Kentucky were in Central Time. Typical east coast biases, I'm afraid :) Please adjust my prior post accordingly [...]

--jhawk at mit.edu
  John Hawkinson