[Python-Dev] Status on PEP-431 Timezones

[Nick Coghlan]

On 26 July 2015 at 18:12, Lennart Regebro <regebro at gmail.com> wrote:
> On Sun, Jul 26, 2015 at 8:05 AM, Tim Peters <tim.peters at gmail.com> wrote:
>> The Python docs also are quite clear about that all arithmetic within
>> a single timezone is "naive".  That was intentional.  The _intended_
>> way to do "aware" arithmetic was always to convert to UTC, do the
>> arithmetic, then convert back.
>
> We can't explicitly implement incorrect timezone aware arithmetic and
> then expect people to not use it. We can make the arithmetic correct,
> and we can raise an error when doing tz-aware arithmetic in a
> non-fixed timezone. But having an implementation we know is incorrect
> and telling people "don't do that" doesn't seem like a good solution
> here.
>
> Why do we even have timezone aware datetimes if we don't intend them
> for usage? There could just be naive datetimes, and timezones, and let
> strftime take a timezone that is used when formatting. And we could
> make date-time creation into a function that parses data including a
> timezone, and returns the UTC time of that data.
>
> But then again, if we do that, we could just as well have that
> timezone as an attribute on the datetime object, and let strftime use
> so it doesn't have to be passed in. And we could let the __init__ of
> the datetime take a timezone and do that initial conversion to UTC.

I think we need to make sure to separate out the question of the
semantic model presented to users from the internal implementation
model here.

As a user, if the apparent semantics of time zone aware date time
arithmetic are accurately represented by "convert time to UTC ->
perform arithmetic -> convert back to stated timezone", then I *don't
care* how that is implemented internally.

This is the aspect Tim is pointing out is a change from the original
design of the time zone aware arithmetic in the datetime module. I
personally think its a change worth making that reflects additional
decades of experience with time zone aware datetime arithmetic, but
the PEP should be clear that it *is* a change.

As Alexander points out, the one bit of information which needs to be
provided by me as a *user* of such an API (rather than its
implementor), is how to handle ambiguities in the initial conversion
to UTC (whether to interpret any ambiguous time reference I supply as
a pre-rollback or post-rollback time). Similarly, the API needs to
tell *me* whether a returned time in a period of ambiguity is
pre-rollback or post-rollback. At the moment the "pre-rollback" flag
is specifically called "is_dst", since rolling clocks back at the end
of DST period is the most common instance of ambiguous times. That
then causes confusion since "DST" in common usage refers to the entire
period from the original roll forward to the eventual roll back, but
the extra bit is only relevant to time zone arithmetic during the
final two overlapping hours when the clocks are rolled back each year
(and is in fact relevant any time a clock rollback occurs, even if the
reason for the rollback has nothing to do with DST).

The above paragraphs represent the full extent of my *personal*
interest in the matter of the datetime module changing the way it
handles timezones - I think there's a right answer from a usability
perspective, and I think it involves treating UTC as the universal
time zone used for all datetime arithmetic, and finding a less
confusing name for the "isdst" flag (such as "prerollback", or
inverting the sense of it to "postrollback", such that 0/False
referred to the first time encountered, and 1/True referred to the
second time encountered).

There's a *separate* discussion, which relates to how best to
*implement* those semantics, given the datetime module implementation
we already have. For the original decimal module, we went with the
approach of storing the data in a display friendly format, and then
converting it explicitly as needed to and from a working
representation for arithmetic purposes. While it seems plausible to me
that such an approach may also work well for datetime arithmetic that
presents the appearance of all datetime arithmetic taking place in
terms of UTC, that's a guess based on general principles, not
something based on a detailed knowledge of datetime in particular
(and, in particular, with no knowledge of the performance
consequences, or if we have any good datetime focused benchmarks akin
to the telco benchmark that guided the original decimal module
implementation).

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia