[tz] Converting cities to tz identifiers (tangent)

[Guy Harris]

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

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

I don't think it's currently intended, by the tzdb maintainers, to be anything other than a backwards-compatibility hack.

The name was *originally* chosen as an indication in the colloquial sense, but that doesn't mean it's still part of the contract for the tzdb, so relying on its existence is relying on something the tzdb doesn't guarantee.  The name itself is unlikely to change, because there's not much point in changing a backwards-compatibility name, but I don't think the tzdb makes any guarantee where it'll point if, for example, New York City leaves the Eastern time zone or New York State decides not to observe DST, even in the face of complaints.

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

"You could do A or B, as they have the same result, and A isn't guaranteed to work, while B is", however, should be a somewhat compelling argument.  Doing B will work on FreeBSD, for example, and doing A won't.

> 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 this case, "static mapping" means "a human manually sets up a mapping between cities and tzdb regions, and, to find out what tzdb region to use a city, that mapping is used", and "dynamic mapping" means "the mapping is done by software looking up the city's location in some database that gives a tz region ID, either doing it every time the mapping is needed, or caching the result".

So, yeah, you *could* do static mapping and manually update the file.  This means you may be taking on a burden that the tzdb maintainers, and maintainers of OSes using the tzdb, may not choose to *possibly* ease by keeping the backward/ links.

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

Why do you conclude this?

> (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.e., those people are forced to deal directly with the mapping list, rather than just asking "what time is it in Boston?" or questions such as that?

> I realize this is a problem the tz database generally tries to pretend to ignore,

"Ignore" in the sense of "treat it as not in scope for the tzdb", if by "the problem" you mean "the fact that tz region ids aren't intended to be end-user friendly".

> in the name of politics,

I've not seen anything to indicate that, for example, we don't provide time zone name-based aliases, or city-name-based aliases, for *political* reasons.

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

Better stated as "some formations are specially privileged because most countries don't get that non-city-specific choice", given that the US's neighbors to the north and south get them too:

	Link	America/Edmonton	Canada/Mountain
	Link	America/Halifax		Canada/Atlantic
	Link	America/Regina		Canada/Saskatchewan
	Link	America/Toronto		Canada/Eastern
	Link	America/Vancouver	Canada/Pacific
	Link	America/Whitehorse	Canada/Yukon
	Link	America/Winnipeg	Canada/Central
	Link	America/St_Johns	Canada/Newfoundland

	Link	America/Mazatlan	Mexico/BajaSur
	Link	America/Mexico_City	Mexico/General
	Link	America/Tijuana		Mexico/BajaNorte

as do some other countries, some of which don't have multiple zones and thus have backward/ aliases giving names or abbreviations for the countries (although Chile has Chile/Continental and Chile/EasterIsland).

So, for *historical* reasons, some countries, including but not limited to the US, have non-city-specific choices; it's not as if this is a case of US maintainers not caring about the rest of the world.