[tz] Converting cities to tz identifiers (tangent)

Julian Cable julian.cable at bbc.co.uk
Tue Feb 20 18:43:27 UTC 2018

I¹ve always used Geonames for this kind of query.

For example for Boston MASS


  "sunrise": "2018-02-20 06:34",
  "lng": -71.063611,
  "countryCode": "US",
  "gmtOffset": -5,
  "rawOffset": -5,
  "sunset": "2018-02-20 17:22",
  "timezoneId": "America/New_York",
  "dstOffset": -4,
  "countryName": "United States",
  "time": "2018-02-20 13:39",
  "lat": 42.358056

Or you can download one of the citiesXXXX.zip from

On 20/02/2018, 17:46, "tz on behalf of John Hawkinson"
<tz-bounces at iana.org on behalf of 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.
>I figured that a review of theory.html and tz-link.html would tell me the
>best way to do this, and it didn't really work out that way.
>The result was that I found myself just reading the "northamererica" file
>and knocking out the states that were unambiguous, and then checking the
>rest against timeanddate.com or time.is. It seems wrong that this
>appeared to be the easiest approach at this scale, so I wonder what
>others would suggest (with the benefit of hindsight).
>And then, in most cases, converting the zones via "backward" to the
>"US/Eastern" American political because doing so seemed more "stable."
>* 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.
>* 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).
>* 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.
>(Both Massachusetts and Florida seem to have current proposals to depart
>US/Eastern and America/New_York.)
>* So, I'm curious if this anecdote triggers any reactions.
>Did I miss an obvious way to address this more simply?
>Is it horrible to have made use of third party websites that lack any
>sort of auditable authority but are probably correct anyhow.
>Is this just not a problem that people have to solve with any frequency?
>Does someone (Paul?) want to convince me that it's Wrong to use the
>"backward" zones, for the narrow (but common) case of United States of
>America cities?
>Thanks for any thoughts.
>--jhawk at mit.edu
>  John Hawkinson

More information about the tz mailing list