Earlier this year I had to write a function to find the current local time given a US address. The naive way to do so would be via a static mapping of state to time zone but there are a few edge cases that preclude doing this; in the interest of cost and speed relative to this specific application I spent a few dollars on a CSV that maps every US ZIP code to UTC offset and whether DST is followed (among other data). pytz takes IANA timezone names so I ended up having to map offset and DST info manually to specific timezones. As it turns out the US has a fair number of weird edge cases for overseas territories and military bases that necessitated the use of things like "Etc" zones [1] that have funky semantics (because of Unix for some reason if Wikipedia is to be believed).
> The naive way to do so would be via a static mapping of state to time zone but there are a few edge cases that preclude doing this
More than a few, state is really the wrong resolution here, US timezones follow counties and native reservations borders.
ZIP codes should probably be good enough but I'd be careful too. If your volume of addresses isn't too crazy, the robust way is to reverse geocode them and use a library that gets you the IANA identifier from timezone shapes.
There used to be at least one airport in a tribal area in the US, that had the timezone of the reservation (not same as state) but the DST of the surrounding state (not same as reservation).
Can't remember the code for it now, had a lot of interesting timezone issues in a previous job.
My favorite is the hopi reservation, which does not observe DST and exists entirely inside of the Navajo reservation, which does observe it, and which exists entirely within Arizona, which again does not observe DST, and exists entirely within the United States which does observe DST in the general case.
I'm guessing that the airport was this one maybe? ttps://en.wikipedia.org/wiki/Window_Rock_Airport
Also IIRC (cum grano salis) the federal buildings in the Hopi reservation do observe DST and the state buildings in the Navajo reservation don't. But don't quote me on any of those actually existing.
A fun fact circa 2012 was I was writing a PHP server that needed to talk to a Windows server to schedule things. Windows server used Microsoft's own timezone system, not IANA or anything like that. I went looking for an implementation of IANA <-> MS conversion. I ended up finding all these forum posts by Windows Phone (RIP) users in Arizona who had the wrong time on their phones. So it was nice to know that 1) there was no fixing it and 2) they eat their own dogfood.
> state is really the wrong resolution here, US timezones follow counties
County is the smallest resolution one can reasonably use, but in terms of what timezones themselves follow, that would be metro areas. I.E. the Chicago metro area has its timezone and cities (or counties, if you will) that are part of that metro region, even when belonging to other states that largely follow a different time zone, follow the metropolis’ tz instead.
(Not arguing with you but clarifying the meaning of “follow” here.)
As a young engineer right out of university back in 1985, one of my early tasks involved merging together a bunch of telemetry data provided on mag tapes recorded at different radar sites (in the USA). One or two of the systems time stamped their data in local time, and all the others used UTC. I remember buying one of those old Farmers' Almanacs in order to make an algorithm to account for DST. When I read the rules, I threw up my arms in despair.
The almanac gave nominal rules for the transitions. But there was a footnote explaining that these transitions had and will continue to be adjusted year to year due to Congressional intervention. I showed this to my boss and said, "If I could write an algorithm that predicted future votes of Congress, I would be a billionaire and could quit this engineering job."
I think in the end I coded the algorithm with the recent known transitions, and the nominal rules for future ones. What else could you do (this was before everyone was networked, and the code ran on standalone computers like a VAX).
I also learned that task of merging three sources of tracking data, each with its own validity and measurement degradation status, was an absolute nightmare. But still easier than predicting future actions of Congress.
A good approach would be to map a zip code to the named timezone (e.g. US/Eastern). Then, if you need to produce the UTC offset, apply the timezone to a date using pytz and get the offset.
The named timezone is special as it is constant. The UTC offset timezone (e.g. "-05:00") and the shorthand name (e.g. "EST") is NOT constant over time for a given location, because of daylight savings time. "US/Eastern" flips between "-05:00" and "-05:00", as well as between "EDT" and "EST".
If you ask someone what their timezone is and offer them offsets or the short names, it causes confusion for everyone.
> Earlier this year I had to write a function to find the current local time given a US address.
I also did something similar earlier this year, though I used a geolocation service to translate address to lat/long coords, and then used lat/long to translate to timezone. (With shortcuts single-timezone states)
I ended up using this python library for lat/long -> timezone converstion:
Yeah you gotta watch out for those "Etc" identifiers, especially if you were thinking about exposing all the identifiers to your users wholesale. The file for them has this comment:
> POSIX has positive signs west of Greenwich, but many people expect positive signs east of Greenwich. For example, TZ='Etc/GMT+4' uses the abbreviation "-04" and corresponds to 4 hours behind UT (i.e. west of Greenwich) even though many people would expect it to mean 4 hours ahead of UT (i.e. east of Greenwich).
[1] https://en.wikipedia.org/wiki/Tz_database#Area