On Sat, Sep 12, 2015 at 2:24 PM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote:
> > On Sat, Sep 12, 2015 at 4:10 PM, Tim Peters <tim.pet...@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)
-- https://mail.python.org/mailman/listinfo/python-list
