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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4