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

Akira Li 4kir4.1i at gmail.com
Thu Apr 16 00:22:44 CEST 2015

Isaac Schwabacher <ischwabacher at wisc.edu> writes:

On 15-04-15, Akira Li <4kir4.1i at gmail.com> wrote:

Isaac Schwabacher <ischwabacher at wisc.edu> writes: > ... > > I know that you can do datetime.now(tz), and you can do datetime(2013, > 11, 3, 1, 30, tzinfo=zoneinfo('America/Chicago')), but not being able > to add a time zone to an existing naive datetime is painful (and > strptime doesn't even let you pass in a time zone).

.now(tz) is correct. datetime(..., tzinfo=tz)) is wrong: if tz is a pytz timezone then you may get a wrong tzinfo (LMT), you should use tz.localize(naivedt, isdst=False|True|None) instead. The whole point of this thread is to finalize PEP 431, which fixes the problem for which localize() and normalize() are workarounds. When this is done, datetime(..., tzinfo=tz) will be correct. ijs

The input time is ambiguous. Even if we assume PEP 431 is implemented in some form, your code is still missing isdst parameter (or the analog). PEP 431 won't fix it; it can't resolve the ambiguity by itself. Notice is_dst paramter in the tz.localize() call (current API).

.now(tz) works even during end-of-DST transitions (current API) when the local time is ambiguous.

More information about the Python-Dev mailing list