3 ms·
Python specific: - `pytz.timezone(timezone_name)` will give you the current offset for that timezone - well, it will at least be some consistent offset - surel
by kortex 4y ago
Python specific:
- `pytz.timezone(timezone_name)` will give you the current offset for that timezone
- well, it will at least be some consistent offset
- surely, every timezone has the same reference starting point?
What `pytz.timezone(name)` actually does is initialize a timezone object at the point in time of the first entry in the tz database for that zone. For example, New York had an offset of 4:56:02 prior to 1883 November 18, 12:03:58 [1]. That is the "starting point" for America/New_York and US/Eastern (which I think is an alias of New_York before a certain date). Which is why you get
>>> pytz.timezone('America/New_York')
<DstTzInfo 'America/New_York' LMT-1 day, 19:04:00 STD>
Ish. Not sure where those 2 seconds went. But that explains why you see that strange 19:04 (-3:56) offset. The real way to use it is
>>> pytz.timezone('America/New_York').localize(your_specific_datetime)
Timezones without a reference time are deceptive.
[1] https://en.wikipedia.org/wiki/Tz_database#Example_zone_and_rule_lines https://en.wikipedia.org/wiki/Tz_database#Example_zone_and_r...
- hermitdev 4y agoCan probably add another falsehood: that timezone information (in particular DST & UTC offsets) will never change. In reality, timezones are very much political and can change at any time with sometimes very little notice. Last major change US folks may remember occurred around 2007, when daylight saving time was expanded by 6 weeks. I know of clocks that are still wrong from that change. At a previous job, I spent over a year working on a library for timezones built on top of Boost. The handling of historical timezones was a particular pain in the ass.