[Python-Dev] Status on PEP-431 Timezones

[Paul Moore]

On 26 July 2015 at 16:33, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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.

I think the current naive semantics are useful and should not be
discarded lightly. At an absolute minimum, there should be a clear,
documented way to get the current semantics under any changed
implementation.

As an example, consider an alarm clock. I want it to go off at 7am
each morning. I'd feel completely justified in writing tomorrows_alarm
= todays_alarm + timedelta(days=1).

If the time changes to DST overnight, I still want the alarm to go off
at 7am. Even though +1 day is in this case actually + 25 (or is it
23?) hours. That's the current semantics.

To be honest, I would imagine, from experience with programmers
writing naive algorithms, that the current semantics is a lot less
prone to error when used by such people. People forget about timezones
until they are bitten by them, and if they are using the convert to
UTC->calculate->convert back model, their code ends up with
off-by-1-hour bugs. Certainly such mistakes can be fixed, and the
people who make them educated, but I like the fact that Python's
typical behaviour is to do what a non-expert would expect. By all
means have the more sophisticated approach available, but if it's the
default then naive users have to either (1) learn the subtleties of
timezones, or (2) learn how to code naive datetime behaviour in Python
before they can write their code. If the current behaviour remains the
default, then *when* the naive user learns about the subtleties of
timezones, they can switch to the TZ-aware datetime - but that's a
single learning step, and it can be taken when the user is ready.

Paul

PS I don't think the above is particularly original - IIRC, it's
basically Guido's argument for naive datetimes from when they were
introduced. I think his example was checking his watch while on a
transatlantic plane flight, but the principle is the same.