[Python-Dev] Status on PEP-431 Timezones
tim.peters at gmail.com
Tue Jul 28 03:36:35 CEST 2015
>> Treating time as UTC with conversions at the application edge might
>> be "cleaner" in some sense, but can make code harder to read for
>> application domain experts.
>> It might be nice to have time zone aware datetime objects with the
>> right(TM) semantics, but those can and should not replace the naive
>> objects we know and love.
[Tres Seaver <tseaver at palladion.com>]
> Interesting. My experience is exactly the opposite: the datetimes which
> "application domain experts" cared about *always* needed to be non-naive
> (zone captured explicitly or from the user's machine and converted to
> UTC/GMT for storage). As with encoded bytes, allowing a naive instance
> inside the borders the system was always a time-bomb bug (stuff would
> blow up at a point far removed from which it was introduced).
I strongly suspect that by "naive objects" here Ronald was really
talking about "naive _arithmetic_": the current behavior where adding
24 hours (or 1 day - exactly the same thing for a timedelta) to an
aware datetime yields a new datetime with the same tzinfo member and
the same local time components, but where the day (and possibly month,
and possibly year) components have moved forward by a day (in the
plain English meaning of "a day").
That behavior has been discussed approximately infinitely often so far
in this thread, and was the overriding context in the message from
which Ronald's quote was pulled.
> The instances which could have safely been naive were all
> logging-related, where the zone was implied by the system's timezone
> (nearly always UTC). I guess the difference is that I'm usually writing
> apps whose users can't be presumed to be in any one timezone. Even in
> those cases, having the logged datetimes be incomparable to user-facing
> ones would make them less useful.
I bet the same is true for Ronald in some of his apps.
So what do _you_ do with datetime arithmetic, Tres? Do you do
datetime calculations at all, or just store/retrieve values as-is? If
the former, are you disturbed that adding timedelta(hours=24) to an
aware datetime object never changes the time components (only the day,
and possibly also month, and possibly also year)? If that has
disturbed you, did you find a way to accomplish what you wanted
instead - or are you still stuck? ;-)
More information about the Python-Dev