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

[Laura Creighton]

In a message of Sun, 13 Sep 2015 16:58:09 -0500, Tim Peters writes:
>[Tim]
>>> Whatever time zone the traveler's railroad schedule uses, so long as
>>> it sticks to just one
>
>[Laura]
>> This is what does not happen.  Which is why I have written a python
>> app to perform conversions for my parents, in the past.
>
>So how did they get the right time zone rules for Creighton?

I was fortunate enough that they were never going there.  But in
investigating the problem I had it filed away under 'really ugly hacks
I might have to write in the future'.  Pre-parsing the file with
special mappings for special lookups seemed the only way to fix this,
at the time, but we have newer databases now than I had then ...
some of which might already know about Creighton.

>pytz solves it by _never_ creating a hybrid tzinfo.  It only uses
>eternally-fixed-offset tzinfos.  For example, for a conceptual zone
>with two possible total UTC offsets (one for "daylight", one for
>"standard"), there two distinct eternally-fixed-offset tzinfo objects
>in pytz.  Then an ambiguous time is resolved by _which_ specific
>tzinfo object is attached.  Typically the "daylight" tzinfo for the
>first time a repeated local time appears, and the "standard" tzinfo
>for its second appearance.

Yes.  I think this is a really great idea.  I have no idea why other
people disagree.

>In return, you have to use .localize() and .normalize() at various
>times, because pytz's tzinfo objects themselves are completely blind
>to the possibility of the total UTC offset changing. .localize() and
>.normalize() are needed to possibly _replace_ the tzinfo object in
>use, depending on the then-current date and time.

Yes.  

>OTOH, `dateutil` does create hybrid tzinfo objects.  No dances are
>ever needed to possibly replace them.  But it's impossible for
>dateutil's tzinfos to disambiguate times in a fold.  Incidentally,
>dateutil also makes no attempt to account for transitions other than
>DST (e.g., sometimes a zone may change its _base_ ("standard") offset
>from UTC).

I find this totally unacceptable.  My conclusion was that hybrid tzinfo
objects were a _really stupid idea_ proposed by somebody who misunderstood
the problem, or rather only understood the most common case.  Smack them
with a dead fish,  https://www.youtube.com/watch?v=i9SSOWORzw4
and get back to work.

>So, yup, if you're thoroughly indoctrinated in pytz behavior, you will
>be accurate but appear insane to Guido ;-)  At a semantic level, a
>pytz tzinfo doesn't capture the notion of a zone with offset changes -
>it doesn't even try to.  All knowledge about offset changes is inside
>the .localize() and .normalize() dances.

I can see why people would like to modify it to spit out this information
when asked.  I don't understand why they would like to have a hybrid
tzinfo.  The notion of replacing tzinfos when they become inappropriate
fills their souls with revulsion, or something?

But, as I said, once you know the pytz way you may be ruined for
appreciating other solutions.