Well, for the US anyway, the names "Eastern", "Mountain", etc. are explicitly provided by 15 USC § 263, and their boundaries are defined in 49 CFR Part 71.  So there is indeed a very specific and exact meaning of "the US Eastern time zone".

Also, a few folks mentioned GeoNames.  That is certainly one arbitrary source of boundary data, but it's unclear as to its sourcing methodology.  Personally, I find the approach used by Even Siroky's Time Zone Boundary Builder project (https://github.com/evansiroky/timezone-boundary-builder) to be much more viable, as it uses Open Street Map as its primary source.  OSM has a good blend of reliable sources and crowd sourcing, so IMHO it aligns well with the TZDB mindset.

Other mechanisms are available here: https://stackoverflow.com/questions/16086962/how-to-get-a-time-zone-from-a-location-using-latitude-and-longitude-coordinates

Note that unlike the US, time zone borders in other parts of the world are much fuzzier.  Depending on your politics, you may disagree about a country boundary and thus also disagree about the local time for a particular point along that boundary.  This has been discussed ad nauseam already, with many examples...

-Matt

From: tz <tz-bounces@iana.org> on behalf of Adam Vartanian via tz <tz@iana.org>
Sent: Wednesday, February 21, 2018 2:27 AM
To: Guy Harris
Cc: tz@iana.org
Subject: Re: [tz] Converting cities to tz identifiers (tangent)
 
>> 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.

In my experience, usage in everyday speech is generally that Arizona is said to spend the winters in Mountain time and the summers in Pacific time, rather than spending the whole year in Mountain standard time.  So if you say "Mountain time" in the summer, people understand that to be UTC-6, even when dealing with people in Arizona.

This is kind of fuzzy definition is insufficient for a project like tzdb, but in a user interface it might well be the best understood option.

- Adam