[tz] Converting cities to tz identifiers (tangent)

[Paul.Koning at dell.com]

I'll give a few of my answers, speaking as an observer on this list.


> On Feb 20, 2018, at 12:46 PM, John Hawkinson <jhawk at mit.edu> wrote:
> 
> This is a bit of a rambling tangent, so sorry.
> 
> I recently had to find tz zones for ~100 American cities, and the process did not go quite as smoothly as I had expected.
> ...
> And then, in most cases, converting the zones via "backward" to the "US/Eastern" American political because doing so seemed more "stable."

I would not recommend that.  "backward" exists, as the name suggests, only for backward compatibility with old naming conventions.

The primary definitions for the zones are the continent/city names, so America/New_York.

> * I was expecting theory.html to give me a little more guidance on the "right" way to do this. As best as I can tell, the "right" (no pun intended) answer is that I should geolocate each city to longitude/latitude (using some unspecified resource, which seems fine), then use one of the datasets or tools at https://data.iana.org/time-zones/tz-link.html#boundaries to convert those locations to zones. This seemed a bit much.

It may seem harder than necessary, but that may be because you haven't fully realized the depths of confusion that politicians will go to.

> * I was also a little surprised to not find someone with a handy list of United States states and territory mappings to tz identifiers (for those cases where the state/territory/district uniquely mapped to a tzid). Other than the comments in "northamerica" (which are not quite as structured as one might like, but are pretty good).

Poking around Indiana will give you a good idea of why this stuff is harder than you might expect.  There you will find some per-county rules, and at some point in time county A might match county B while at another point in history it uses different rules.

So yes, the answer really is as hard as it seems to be.

1. For each defined done (America/*) find the boundaries of that zone, in one of the published shapefile databases.

2. For each city you're interested in, use its coordinates to match against the shape data from step 1 to learn what zone it is in.

> * 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:
> ...
> My conclusion was that in general, for most locations, the US/* ("backward") form seemed the better choice.
> 
> (Both Massachusetts and Florida seem to have current proposals to depart US/Eastern and America/New_York.)

Well, US/x is just a link to America/y, for suitable y.  So there isn't any actual difference.

The real problem is this: If some of the places in an existing zone change their rules to differ from those of the rest of the zone, the new definition will have two zones where there used to be just one.  Presumably, one of the two will retain its existing name; the other will get a new name assigned according to the naming conventions given.

Consider a slightly stranger example: suppose that NY leaves the current Eastern timezone.  In that case, I would expect there to be a a America/New_York zone with the NEW rule for NY (only) and the existing America/New_York ("Eastern time") zone would get a new name because NYC is no longer in it.  That might be America/Philadelphia; probably not America/Boston given the sizes of those cities.

So to answer the question of the most stable identifier to use -- there isn't one.  You can definitely associate today's zone name for each city with that city.  But that doesn't help predict what might happen next year, because you'd just be guessing what politicians might do and in general that isn't feasible.

	paul