[Python-Dev] Status on PEP-431 Timezones

[Tim Peters]

[ISAAC J SCHWABACHER <ischwabacher at wisc.edu>]
>>> ...
>>> I think the right perspective is that a time zone *is* the function that its
>>> `fromutc()` method implements,

[Tim]
>> Fine by me ;-)

[Isaac]
> My issue is that you're computing `fromutc()`, which is a function, in
> terms of `dst()` and `utcoffset()`, which aren't.

I know.  That's not "an issue" that will gain traction, though ;-)

> I think this is backwards; `dst()` and `utcoffset()` should be computed
> from `fromutc()` plus some additional information that has to be present
> anyway in order to implement `fromutc()`.

Memory lane:  that additional information doesn't exist now.  I think
it "should have", but at the time, as I recall there was fatal
opposition to storing an `isdst` flag because it would consume an
extra byte in the pickle format.  That was enough to kill it:
datetime development was paid for by a company very concerned about
pickle sizes ;-)

> With the extra bit, `dst()` and `utcoffset()` become partial functions, which
> makes it *possible* to get the right answer in all cases, but it's still simpler
> to start with the total function and work from there.

Well, maybe simpler for you, but I think not in general.  At the time,
all aspects of datetime's development were vigorously debated, but
mostly on Zope Corp (the company paying for it) wikis and mailing
lists.  While some people didn't care about time zones at all, most
did.  Of the latter:

- All were keenly aware of the need to incorporate UTC offsets.
- All were keenly aware of the need to accommodate "daylight time" schemes.
- None gave a fig about anything else.

Very late in the game, examples were given of localities that had in
fact changed their UTC offsets from time to time, but as curiosities
rather than as "issues".  That's when I created fromutc() - it was a
last-second addition.  I cared enough to make it _possible_ to
accommodate such cases, but there was no interest (or time) to cater
to them directly.  Instead fromutc() was written to use only the
already-existing utcoffset() and dst().  Everyone already knew how to
use the latter:  they directly corresponded to the two things everyone
cared about keenly from the start.

That doesn't _preclude_ anyone from writing a more-general fromutc(),
and I encourage, for example, you to do so ;-)  I agree it's the most
fundamental thing from an abstract mathematical view, but "UTC offset"
and "DST offset" fit most peoples' brains a hell of a lot better than
"collection of piecewise continuous monotonically increasing functions
whose images don't overlap too much" ;-)

>>> .... Daylight Saving Time is a red herring,

>> Overstated ....

> I stand by what I meant by this, even if I did a bad job of expressing
> the point. Assuming that all time zone discontinuities are due to DST
> changes breaks many time zones (really almost all of the Olson time
> zones, though only for a vanishingly small fraction of datetimes),

It's use cases that are missing here:  who needs to convert historic
times to/from UTC. and where the "problem times" are generally
arranged by politicians to occur when most people are sleeping?
That's why nobody really cared about offset-changing zones at the
start.  Yes, such zones exist, but times recorded in such zones are in
yesterday's databases we don't care about anymore except maybe to
display the values.

> but that's not the point I was making. The point is that it doesn't buy us
> anything.

Au contraire:  as above, it bought datetime a model people thought
they understood at once, since almost everyone has wrestled with UTC
offsets and daylight-time switches in ordinary daily life.  Implement
utcoffset() and dst(), and you're done.  Even if you're really not,
you _think_ you are, so you slumber peacefully then ;-)

> Though this is probably obscured by all the markup, the more general
> algorithm I gave is also simpler than the one in the comment in datetime.py,
> and the reason for that is that it solves an easier problem, but one that
> serves our practical purposes just as well.

It's heavily obscured by the heavy markup.  Write some Python code
instead?  I expect few people will try to untangle the meaning
otherwise.

As for whether it's simpler - eh, don't know.  Here's the actual code,
stripped of error-checking:

    def fromutc(self, dt):
        dtoff = dt.utcoffset()
        dtdst = dt.dst()
        delta = dtoff - dtdst
        if delta:
            dt += delta
            dtdst = dt.dst()
        return dt + dtdst

Will your code run faster?  Have fewer conditionals?  Fewer lines?
Shorter lines?  Less nesting?  Fewer operations?  Important to me,
though, is that your code should be far more self-evidently _correct_,
provided the reader understands the math underlying it (which will
require - as this code does - referring to a relatively massive wall
of text to explain it).

> ...
> I went too far in inferring your viewpoint from your code.  I don't find fault
> with the explanation on its own terms. But adding zoneinfo to the stdlib,
> as PEP 431 proposes to do, requires making weaker assumptions and
> asking a different question than the one answered in the comment.

pytz is already in wide use, yes?  How many complaints are there about
non-functioning cases?  I have no idea.

> As a mathematician at heart, I have a deep and abiding conviction, which
> I expect nobody else to share, that purity begets practicality in the long run.
> At least if you've found the right abstraction.

Guido is a mathematician by training, yet has an opposing view in this
case.  So:  resolved, there's no point in asking mathematicians about
anything, since they never agree ;-)


>>> [eliding a more-general view of what time zones "really" are]

> [note for people just joining this conversation: I think the information in
>  the elision is critical to understanding what I'm talking about]

By all means, yes!  Note that I found it helpful to paste it into a
web-based LaTeX renderer first, because it was close to impossible to
read otherwise.

> ...
> But these assumptions didn't come out of nowhere. They're the assumptions
> behind zoneinfo, weakened as much as possible without making the problem
> any harder. It's hard to weaken them further and still have anything to work
> with. (See? I *do* still have a sense of practicality!)

Good to hear ;-)

> Nobody wants to read me discussing this at great length, but I'll say
> that I don't expect any legislative body to have the collective
> mathematical sophistication necessary to violate piecewise
> continuity or computability. If you really want to troll me, I invite you
> to take over a government and institute a time zone based on the (Weierstrass
> function)[1].

No, politicians don't surprise with their sophistication, but with
their stupidity :-)  For example, when Mike Huckabee becomes US
President in 2016, I expect he'll put the US on Apocalypse Time.  This
will count time _backwards_ starting from now and ending with
0:00:00.000000 at the stroke of (what we now think of as) midnight at
the end of (what we now think of as) 2099.  And there goes "strictly
increasing" ;-)


> Parts of five US states (Alaska, North Dakota, Indiana, Kentucky
> and Michigan) have changed their standard time since 1970.

For example, North Dakota's Mercer County switched from US Mountain to
US Central on or about 7 Nov 2010.  That's the kind of thing you're
talking about?  Eh.  I don't believe anyone anywhere had a "time zone"
designed specifically for Mercer County before - and probably still
doesn't.  But, sure, if somebody really wants to create such a beast,
they should be able to.  Everyone else in the world will use US
Central for it now, and never know the difference ;-)

> But I'll admit that mentioning Riyadh was a low blow.

It was fun!  I just wish all examples were that engagingly bizarre :-)

>> ...
>> For that reason, it was wholly intentional that datetime +
>> timedelta treats datetime as "naive". ...

> Sigh. This offends my sensibilities so much, but I've said my bit
> on this elsewhere on this list, and I don't think I have the right abstraction
> to cut this Gordian knot.  Point conceded.

I should point out that I haven't paid any attention to datetime for
some years now (other than being a happy casual user), so don't know
what you previously said, and can't even say whether Guido is still of
the same opinion.  However, if he had changed his mind, he would have
used his time machine to change all he previously wrote about it, and
I didn't see any evidence of that.