[Datetime-SIG] Are there any "correct" implementations of tzinfo?

Guido van Rossum guido at python.org
Sun Sep 13 00:24:58 CEST 2015

On Sat, Sep 12, 2015 at 2:24 PM, Alexander Belopolsky <
alexander.belopolsky at gmail.com> wrote:

> On Sat, Sep 12, 2015 at 4:10 PM, Tim Peters <tim.peters at gmail.com> wrote:
>> "A potential problem" with .astimezone()'s default is that it _does_
>> create a fixed-offset zone.  It's not at all obvious that it should do
>> so.  First time I saw it, my initial _expectation_ was that it
>> "obviously" created a hybrid tzinfo reflecting the system zone's
>> actual daylight rules, as various "tzlocal" implementations outside of
>> Python do.
> The clue should have been that  .astimezone() is an instance method and
> you don't need to know time to create a hybrid tzinfo.  If a Local tzinfo
> was available, it could just be passed to the .astimezone() method as an
> argument.  You would not need .astimezone() to both create a tzinfo and
> convert the datetime instance to it.
> Still, I agree that this was a hack and a very similar hack to the one
> implemented by pytz.   Hopefully once PEP 495 is implemented we will
> shortly see "as intended" tzinfos to become more popular.

The repeated claims (by Alexander?) that astimezone() has the power of
pytz's localize() need to stop. Those pytz methods work for any (pytz)
timezone -- astimezone() with a default argument only works for the local
time zone. (And indeed what it does is surprising, except perhaps to pytz

--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20150912/044472ce/attachment.html>

More information about the Python-list mailing list