But seriously, why are timezones so difficult? Out of all the things that I would expect to “just work,” this one would be near the top of the list. Python is great, but it’s definitely not batteries-included and I find myself still frequently navigating an ecosystem of broken, stale or “incorrect” external libraries. I attribute this to the horrible state that Python online learning is in, probably because it is one of the most popular languages out there, there are so many misleading resources. It was a pleasure learning other languages, like Go or Perl, where I can turn to vetted and single sources of information for the “right way” to do things.
Thanks for posting this, literally just helped solve a ghost bug that we’ve been sporadically encountering for months now.
Alice wants to schedule a meeting with Bob. Alice proposes “1:30 Tuesday”.
Level 1: What actual point in time does that mean? What point in time is “1:30 Tuesday” in Alice’s time zone? What is it in Bob’s time zone? What is it in UTC (which is presumably what the meeting server will store? How are you collecting the time zone information from both Alice and Bob in order to display the correct point in time to both of them? What about when Bob decides Carol (who is potentially in a third time zone) should also be on the meeting?
Level 2: What actual point in time does that mean? What if Alice is scheduling the meeting from the time zone she normally lives in, but will be traveling and in a different time zone on the date of the meeting?
Level 3: What actual point in time does that mean? What if Bob’s jurisdiction will switch to some sort of “summer” or “winter” time around that date? What if Carol’s jurisdiction is changing their timezone rules this year? Or: the meeting has already happened, but now an auditor is making sure Alice and Bob and Carol all stuck to their legal working hours. What if the time-zone rules for their jurisdictions have changed in the intervening period?
And these are just the most basic top-of-mind things that can come up with time zones. The full reality is almost unbelievably complex, and it is that way largely because time zones are designed for messy humans who want their local time to vaguely match perceived solar time, rather than for computers which don’t care about that but do want consistent precise rules to follow.
And the difficulty and complexity are reflected in the fact that every programming language I’m aware of has warts and complexity and difficulty and “oh, don’t use that” around dates and times. It’s not that Python is somehow uniquely unable to get it right where everyone else did – it’s that lots of people have gotten it wrong, but Python’s popularity amplifies your awareness of the Python-specific incidence of wrongness.
It’s not that Python is somehow uniquely unable to get it right where everyone else did – it’s that lots of people have gotten it wrong
I have exactly once attempted to tackle time information in detail (not in Python) and this is completely the right take. The amount of footguns surrounding our concept of time, irrespective of the language involved, is immense. I will never attempt this again, merely make it clear that my code does X to attempt to handle time information and everything else is an assumption waiting to fail. i.e. this note on Apple Cloud Notes Parser’s date feature:
Note: This feature is not intended to be robust. It does not smartly handle differences in timezones, nor convert to UTC.
starts sweating nervously
But seriously, why are timezones so difficult? Out of all the things that I would expect to “just work,” this one would be near the top of the list. Python is great, but it’s definitely not batteries-included and I find myself still frequently navigating an ecosystem of broken, stale or “incorrect” external libraries. I attribute this to the horrible state that Python online learning is in, probably because it is one of the most popular languages out there, there are so many misleading resources. It was a pleasure learning other languages, like Go or Perl, where I can turn to vetted and single sources of information for the “right way” to do things.
Thanks for posting this, literally just helped solve a ghost bug that we’ve been sporadically encountering for months now.
This article was written in 2018. As of Python 3.9, there is now the “zoneinfo” standard library which I believe should be considered best practice when working with time zones. https://docs.python.org/3/library/zoneinfo.html#module-zoneinfo
Alice wants to schedule a meeting with Bob. Alice proposes “1:30 Tuesday”.
Level 1: What actual point in time does that mean? What point in time is “1:30 Tuesday” in Alice’s time zone? What is it in Bob’s time zone? What is it in UTC (which is presumably what the meeting server will store? How are you collecting the time zone information from both Alice and Bob in order to display the correct point in time to both of them? What about when Bob decides Carol (who is potentially in a third time zone) should also be on the meeting?
Level 2: What actual point in time does that mean? What if Alice is scheduling the meeting from the time zone she normally lives in, but will be traveling and in a different time zone on the date of the meeting?
Level 3: What actual point in time does that mean? What if Bob’s jurisdiction will switch to some sort of “summer” or “winter” time around that date? What if Carol’s jurisdiction is changing their timezone rules this year? Or: the meeting has already happened, but now an auditor is making sure Alice and Bob and Carol all stuck to their legal working hours. What if the time-zone rules for their jurisdictions have changed in the intervening period?
And these are just the most basic top-of-mind things that can come up with time zones. The full reality is almost unbelievably complex, and it is that way largely because time zones are designed for messy humans who want their local time to vaguely match perceived solar time, rather than for computers which don’t care about that but do want consistent precise rules to follow.
And the difficulty and complexity are reflected in the fact that every programming language I’m aware of has warts and complexity and difficulty and “oh, don’t use that” around dates and times. It’s not that Python is somehow uniquely unable to get it right where everyone else did – it’s that lots of people have gotten it wrong, but Python’s popularity amplifies your awareness of the Python-specific incidence of wrongness.
I have exactly once attempted to tackle time information in detail (not in Python) and this is completely the right take. The amount of footguns surrounding our concept of time, irrespective of the language involved, is immense. I will never attempt this again, merely make it clear that my code does X to attempt to handle time information and everything else is an assumption waiting to fail. i.e. this note on Apple Cloud Notes Parser’s date feature:
tl;dr don’t use pytz, use dateutil
Jeez what a mindfuck. I’m reasonably sure I made mistakes with pytz in codebases in the past.