[Python-Dev] Status on PEP-431 Timezones

Tim Peters tim.peters at gmail.com
Tue Jul 28 22:26:57 CEST 2015


[Łukasz Rekucki <lrekucki at gmail.com>]
>> Maybe instead of trying to decide who is "wrong" and which approach is
>> "broken", Python just needs a more clear separation between timezone
>> aware objects and "naive" ones?

[Lennart Regebro <regebro at gmail.com>]
> Well, the separation is pretty clear already.

I preemptively ;-) agreed with Lukasz on this:  it's downright strange
that we have datetime objects the docs call "aware" that nevertheless
_act_ as if they were "naive" in some cases of arithmetic.  That was
the intended design, but it is strange in that respect.  So it goes.

> Tim wants to have naive timezone aware objects, ie datetime objects that have
> a time zone but ignores the time zone, except when converting to other time zones.

That's not about what I want.  It's what Python _does_.  We can't wish
away how the language already works.  Guido designed it that way (with
an enormous amount of public input & debate), and I did the vast bulk
of the implementations.  It so happens I like Guido's design, but none
of that ever depended on what Tim wanted datetime to do (except in
minor respects, like adding the .replace() and .fromutc() methods,
which weren't part of the original design - I made those up based on
painful experience with many iterations of ever-changing prototypes -
but my role in arithmetic was just to implement the design specs).

> I have yet to see a use case for that.

Of course you have.  When you address them, you usually dismiss them
as "calendar operations" (IIRC).  In some of those cases, you
correctly pointed out that the user could have done as well (based on
all they explicitly revealed about their app's requirements) with a
naive datetime object.  In other cases, you made the same claim but
seemingly incorrectly (like any app that needs to track the local
clocks across multiple timezones with inter-zone conversions, and also
needs to do "calendar operations" in those timezones, and -
unsurprisingly! - uses Python's datetime arithmetic to implement such
operations.  It's unsurprising they do so because that was always the
intended and documented way to do so - and it has always worked for
these purposes).

But it doesn't matter whether you _call_ them "calendar operations",
or anything else.  What they're called doesn't change any of the
high-order bits:  they are use cases, they already work, they have
worked that way for a dozen years (an eternity in "computer time"),
they were always intended to work that way, and the docs have always
said they work that way.

I do think you're missing my fundamental objection:  no matter what
intended and documented thing datetime (or any other module) has done
all along, and regardless of whether I loved it or hated it, I'd be
just as annoying about insisting we cannot intentionally break
existing code using that thing in non-trivial ways without a
justification so compelling that I can't recall a case of it ever
happening.

If Python had been doing "Lennart arithmetic" all along, and Guido
proposed changing to "Guido arithmetic" in Python 2 and/or Python 3,
I'd be equally opposed to his proposal (& despite that I prefer
Guido's vision of how datetime arithmetic should work - "tough luck -
it's too late". And he'd eventually agree.  Be like Guido ;-) ).

Given Guido's brief message, I'll cut the weasel words, confident that
I'm still channeling his intent in this area:  major
backward-incompatible changes (like altering the meaning of arithmetic
using already-existing objects and operations) are not going to
happen.   It's clear now that he'd even remain opposed to such a
change in a hypothetical everything-can-change Python 4, because he
still likes his original design.

So please move on.  New objects, new operations, new functions, new
methods, new optional arguments on existing methods, even new modules
... all remain on the table.  Changing the meaning of code that some
users are perfectly happy with was never really _on_ the table (which
would have been made clear before if the PEP had spelled out that
changes to the results of arithmetic wouldn't be restricted to a tiny
number of annoying-to-everyone-regardless edge cases).

Even convincing _everyone_ that "it's broken" (which will never happen
either) wouldn't change one jot of this.  Look:

>>> 0.1 + 0.1 + 0.1 == 0.3
False

That will remain "broken" forever too (except, perhaps, until Python
4). and despite that it's one of the most frequent of all user
complaints.

So at worst you're in good company ;-)


More information about the Python-Dev mailing list