[Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

And I would want to remind everyone again that this is not a question
of the problem being impossible. It's just really complex to get right
in all cases, and that always having the UTC timestamp around gets rid
of most of that complexity.

On Sat, Jul 25, 2015 at 3:39 AM, Tim Peters <tim.peters at gmail.com> wrote:
> [ISAAC J SCHWABACHER <ischwabacher at wisc.edu>]
>> ...
>> I disagree with the view Tim had of time zones when he wrote that comment
>> (and that code). It sounds like he views US/Eastern and US/Central as time
>> zones (which they are), but thinks of the various America/Indiana zones as
>> switching back and forth between them, rather than being time zones in their
>> own right
>
> You can think of them anyway you like.  The point of the code was to
> provide a simple & efficient way to convert from UTC to local time in
> all "time zones" in known actual use at the time; the point of the
> comment was to explain the limitations of the code.  Although, as
> Allexander noted, the stated assumptions are stronger than needed.
>
>> I think the right perspective is that a time zone *is* the function that its
>> `fromutc()` method implements,
>
> Fine by me ;-)
>
>> although of course we need additional information in order to actually
>> compute (rather than merely mathematically define) its inverse. Daylight Saving
>> Time is a red herring,
>
> Overstated.  DST is in fact the _only_ real complication in 99.99% of
> time zones (perhaps even 99.9913% ;-) ).  As the docs say, if you have
> some crazy-ass time zone in mind, fine, that's why fromutc() was
> exposed (so your; crazy-ass tzinfo class can override it).
>
>> and assumptions 2 and 4
>
> Nitpick:  4 is a consequence of 2, not an independent assumption.
>
>> in that exposition are just wrong from this point of view.
>
> As above, there is no particular POV in this code:  just a specific
> fromutc() implementation, comments that explain its limitations, and
> an invitation in the docs to override it if it's not enough for your
> case.
>
>> In the worst case, Asia/Riyadh's two years of solar time completely shatter
>> these assumptions.
>
> Sure.  But, honestly, who cares?  Riyadh Solar Time was so
> off-the-wall that even the Saudis gave up on it 25 years ago (after a
> miserable 3-year experiment with it).  "Practicality beats purity".
>
>> [eliding a more-general view of what time zones "really" are]
>
> I'm not eliding it because I disagree with it, but because time zones
> are political constructions.  "The math" we make up may or may not be
> good enough to deal with all future political abominations; for
> example:
>
>> ...
>> This assumption would be violated if, for example, some jurisdiction
>> decided to fall back two hours by falling back one hour and then
>> immediately falling back a second hour.  I recommend the overthrow
>> of any such jurisdiction and its (annexation by the Netherlands)[3].
>
> That's not objectively any more bizarre than Riyadh Solar Time.
> Although, if I've lived longer than you, I may be more wary about the
> creative stupidity of political schemes ;-)
>
>
>> ... (Lennart, I think this third assumption is the important part of your "no
>> changes within 48 hours of each other" assumption,
>
> The "48 hours" bit came from Alexander.  I'm personally unclear on
> what Lennart's problems are.
>
>> ...
>> All of these computations can be accomplished by searches of ordered lists
>> and applications of $fromlocal_i$.
>
> Do you have real-world use cases in mind beyond supporting
> long-abandoned Riyadh Solar time?
>
>> ...
>> With this perspective, arithmetic becomes "translate to UTC, operate, translate
>> back", which is as it should be.
>
> There _was_ a POV in the datetime design about that:  no, that's not
> how it should be.  Blame Guido ;-)  If I add, say, 24 hours to noon
> today, I want to get noon tomorrow, and couldn't care less whether DST
> started or stopped (or any other political adjustment was made) in
> between.  For that reason, it was wholly intentional that datetime +
> timedelta treats datetime as "naive".  If that's not what someone
> wants, fine, but then they don't want Python's datetime arithmetic
> BTW, there's no implication that they're "wrong" for wanting something
> different; what would be wrong is insisting that datetime's POV is
> "wrong".  Both views are valid and useful, depending on the needs of
> the application.  One had to picked as the built-in behavior, and
> "naive" won.
>
>> ...
>> But IIUC what Lennart is complaining about
>
> I don't, and I wish he would be more explicit about what "the
> problem(s)" is(are).
>
>> is the fact that the DST flag isn't part of and can't be embedded into a local time,
>> so it's impossible to fold the second parameter to $fromlocal$ into $t$.  Without
>> that, a local time isn't rich enough to designate a single point in time and the
>> whole edifice breaks.
>
> You can blame Guido for that too ;-) , but in this case I disagree(d)
> with him:  Guido was overly (IMO) annoyed by that the only apparent
> purpose for a struct tm's tm_ isdst flag was to disambiguate local
> times in a relative handful of cases.  His thought:  an entire bit
> just for that?!  My thought:  get over it, it's one measly bit.
>
> my-kingdom-for-bit-ingly y'rs  - tim