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.
--
https://mail.python.org/mailman/listinfo/python-list
