[Python-Dev] Status on PEP-431 Timezones (original) (raw)

Stuart Bishop stuart at stuartbishop.net
Fri Apr 10 12:59:43 CEST 2015

On 9 April 2015 at 04:38, Lennart Regebro <regebro at gmail.com> wrote:

So is adopting pytz's expanded API into the stdlib really a big problem? Maybe, maybe not. But that API is also needlessly complicated, precisely because it's working around the limitations of datetime.tzinfo. In the PEP I remove those limitations but keep the simpler API. With a solution based on how pytz does it, I don't think that's possible.

Speaking at the pytz author and maintainer, I can categorically state that pytz's extended API sucks.

Is this really adequate? pytz's implementation handles far more than "is DST or not", it also correctly handles historical timezone changes. How would those be handled under this proposal? Those would still be handled. The flag is only to flag if it's DST or not in a timestamp that is otherwise ambiguous.

Yeah. I look forward to datetime growing an isdst flag, which if nothing else means they can round trip with the 9-tuples used by the time module and a simple LocalTz class written that uses time.mktime and friends. I'd have done it myself if I remembered any C. At that point, the most disgusting parts of pytz can be torn out, giving it the standard documented API and I'm more than happy to do that bit.

-- Stuart Bishop <stuart at stuartbishop.net> http://www.stuartbishop.net/

More information about the Python-Dev mailing list