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.
-- https://mail.python.org/mailman/listinfo/python-list
