[Python-Dev] Status on PEP-431 Timezones

[Stuart Bishop]

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 "is_dst=None", which
>> seems like a copy and paste error from the definition of
>> AmbiguousTimeError.
>
> The PEP is correct here. If you explicitly specify is_dst, 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,
> is_dst=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, is_dst=None
> refuses to guess and you get the exception.
>
> So does this mean that consistent use of is_dst=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/