[Datetime-SIG] Are there any "correct" implementations of tzinfo?

[Tim Peters]

[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).