[Python-Dev] Status on PEP-431 Timezones

Tim Peters tim.peters at gmail.com
Sun Jul 26 02:56:52 CEST 2015

[Lennart Regebro <regebro at gmail.com>]
>>> 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.

>> Could you please be explicit about what "the problem" is?  Everyone
>> here is guessing at what you think "the problem" is.

> The problem is that it is exceedingly complicated to get all the
> calculations back and forth between local time and UTC to be correct
> at all times and for all cases. It really doesn't get more specific
> than that. I don't remember which exact problem it was that made me
> decide that this was not the correct solution and that we should use
> UTC internally, but I don't think that matters, because I'm also sure
> that it was not the last case, as I was far from near the end in
> adding testcases.

I believe everyone here is saying it "shouldn't be" exceedingly
complicated, or even particularly hard, if you add the is_dst flags
the PEP says it would add.

But is the PEP complete?  Under the "Postponement" section, it says:

    The implementation has turned out to be exceedingly complex,
    due to having to convert back and forth between the local time
    and UTC during arithmetic and adjusting the DST for each
    arithmetic step, with ambiguous times being particularly hard
    to get right.

However, the _body_ of the PEP said nothing whatsoever about altering
arithmetic.  The body of the PEP sounds like it's mainly just
proposing to fold the pytz package into the core.  Perhaps doing
_just_ that much would get this project unstuck?  Hope springs eternal

> Once again I'm sure it's not impossible to somehow come up with an
> implementation and an API that can do this based on local time, but
> once again I am of the opinion that it is the wrong thing to do. We
> should switch to using UTC internally, because that will make
> everything so much simpler.

Like what?  I'm still looking for a concrete example of what "the
problem" is (or even "a" problem).

> I am in no way against other people implementing this PEP, but I think
> you will end up with very complex code that will be hard to maintain.

Somebody first needs to define what "the problem" is ;-)

> There really is a reason every other date time implementation I know
> of uses UTC internally,

Yes, but the fundamental reason datetime does not is that Guido
consciously and deliberately decided that "naive datetime" would be
most useful most often for most users.  That's why "naive" objects are
the default.  And even for "aware" objects, arithmetic staying within
a single time zone was deliberately specified to be "naive" too.  My
guess is that all other datetime implementations you know of have no
concept of "naive" datetimes. let alone make naive datetimes primary.
Small wonder, if so, that they're all different in this way.

That's a design decision not everyone likes, and certainly isn't
suitable for all purposes, but the debate over that ended a dozen
years ago when the decision was made.  If your vision of PEP 431
_changes_ that design decision (which it sure _sounds_ like it wants
to based on what you're typing here, but which PEP 431 itself does not
appear to say - impossible to tell which from here without any
specific example(s)), that may account for all sorts of complications
that aren't apparent to me.

> and there really is a reason why everyone always recommends storing date
> times in UTC with the time zone or offset separately.

Well, that's the second thing they recommend - and they can already do
that.  The first thing to recommend is to use naive objects in any
application where that's possible, so that you don't have to bother
with _any_ time zone esoterica, surprises, complications or overheads.
After all, it's 7:54 PM as I type this, and that's perfectly clear to
me ;-)

More information about the Python-Dev mailing list