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

[Guido van Rossum]

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
users.)

-- 
--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>