[tz] Converting cities to tz identifiers (tangent)

Guy Harris guy at alum.mit.edu
Wed Feb 21 01:23:23 UTC 2018

On Feb 20, 2018, at 3:27 PM, Paul G <paul at ganssle.io> wrote:

>> What is meant by "the US Eastern time zone"? 
> I think the colloquial meaning applies. The case I'm thinking of would be things like a hotline which advertises its hours in "Eastern time" rather than the time zone of a specific city, or a distributed team following roughly US time zone rules that schedules their meetings in "Eastern time" even though the members of the team are in various locations.

Fortunately, every US location in the Eastern time zone observes DST, so the city doesn't currently matter.

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.

> This is mooted if US/Eastern is defined forever after as being linked to America/New_York, but if it continues to carry the colloquial meaning, there *are* cases where it makes sense to eagerly resolve it rather than save as a mapping.

Resolve it to what?

> Additionally I suppose there is a question of whether there exists a stable, dependable source of mappings between these abstract zones and the tzdb keys that apply at to them,

tzdb ids don't correspond to time zones, they correspond to tz regions.  The boundaries of time zones shift over time; the only way in which the boundaries of tz regions should shift is that a given tz region splits into two or more regions if some part or parts of that tz region end up in a different time zone due to a time zone boundary shift, decide to change their observance of DST, or something such as that.

"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.  That would map it to America/New_York, and "the US Central time zone" would map to America/Chicago, and "the US Mountain time zone" would map to America/Denver (sorry, Arizona!), and "the US Pacific time zone" would map to America/Los_Angeles.

The resulting tz region would not necessarily be the *only* tz region that's in the time zone in question, however.

> given that the ones in tzdb exist only in backward/

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

More information about the tz mailing list