[Python-Dev] Status on PEP-431 Timezones (original) (raw)

Stuart Bishop stuart at stuartbishop.net
Sat Apr 11 07:48:27 CEST 2015

On 10 April 2015 at 22:57, Glenn Linderman <v+python at g.nevcal.com> wrote:

On 4/10/2015 5:27 AM, Stuart Bishop wrote:

P.S. The description of NonExistentTimeError in the PEP doesn't seem quite right, as it currently says it will only be thrown if "isdst=None", which seems like a copy and paste error from the definition of AmbiguousTimeError. The PEP is correct here. If you explicitly specify isdst, you know which side of the transition you are on and which offset to use. You can calculate datetime(2000, 12, 31, 2, 0, 0, 0).astimezone(foo, isdst=False) using the non-DST offset and get an answer. It might not have ever appeared on the clock on your wall, but it is better than a punch in the face. If you want a punch in the face, isdst=None refuses to guess and you get the exception. So does this mean that consistent use of isdst=False throughout the summer would allow for people that refuse to accept government regulation into their timekeeping, and are willing to be out of step with their neighbors, would be able to match their software to their wall-clock time?

No, this logic is only done when necessary. The goal is that, by default, you can convert any naive timestamp into any timezone without raising an exception. The vast majority of callsites do not require perfect accuracy, but just want a good enough result they can display or log. They do not want to worry about Heisenbugs, where if their application is being run in a timezone with DST transitions then it fails for one hour per year in the middle of the night. If you do need accuracy, you explicitly override the default arguments and take responsibility for handling the exceptions.

-- Stuart Bishop <stuart at stuartbishop.net> http://www.stuartbishop.net/

More information about the Python-Dev mailing list