[Tim] >> Me too - except I think acceptance of 495 should be contingent upon >> someone first completing a fully functional (if not releasable) >> fold-aware zoneinfo wrapping.
[Alex] > Good idea. How far are you from completing that? In my head, it was done last week ;-) In real life, I'm running out of spare time for much of anything anymore. I don't expect to be able to resume zoneinfo fiddling for at least 2 weeks. >> Details have a way of surprising, and >> we should learn from the last time we released a tzinfo spec in the >> absence of any industrial-strength wrappings using it. > I completely agree. That's why I am adding test cases like Lord Hope Island > and Vilnius to datetimetester. That helps a lot, but "industrial-strength" implies "by algorithm". There are far too many zones to deal with by crafting a hand-written class for each. > I will try to create a zoneinfo wrapping prototype as well, but I will > probably "cheat" and build it on top of pytz. It would be crazy not to ;-) Note that Stuart got to punt on "the hard part": .utcoffset(), since pytz only uses fixed-offset classes. For a prototype - and possibly forever after - I'd be inclined to create an exhaustive list of transition times in local time, parallel to the list of such times already there in UTC. An index into either list then gives an index into the other, and into the list of information about the transition (total offset, is_dst, etc). -- https://mail.python.org/mailman/listinfo/python-list
