[Python-Dev] Status on PEP-431 Timezones (original) (raw)
Isaac Schwabacher ischwabacher at wisc.edu
Thu Apr 16 00:36:50 CEST 2015
- Previous message (by thread): [Python-Dev] Status on PEP-431 Timezones
- Next message (by thread): [Python-Dev] Status on PEP-431 Timezones
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 15-04-15, Akira Li <4kir4.1i at gmail.com> wrote:
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 whichlocalize()
andnormalize()
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 isdst paramter in thetz.localize()
call (current API).
...yeah, I forgot to throw that in there. It was supposed to be there all along. Nothing to see here, move along.
.now(tz) works even during end-of-DST transitions (current API) when the local time is ambiguous.
I know that. That's what I was complaining about-- I was trying to talk about how astimezone() was going to be inadequate even after the PEP was implemented because it couldn't turn naive datetimes into aware ones, and people were giving examples that started with aware datetimes generated by now(tz), which completely went around the point I was trying to make. But it looks like astimezone() is going to grow an is_dst parameter, and everything will be OK.
ijs
- Previous message (by thread): [Python-Dev] Status on PEP-431 Timezones
- Next message (by thread): [Python-Dev] Status on PEP-431 Timezones
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]