[Python-Dev] Status on PEP-431 Timezones

[Tim Peters]

[Tim]
>> Python didn't implement timezone-aware arithmetic at all within a
>> single time zone.  Read what I wrote just above.  It implements naive
>> arithmetic within a single time zone.

[Jon Ribbens <jon+python-dev at unequivocal.co.uk>]
> This usage of "time zone" is confusing.

Ha!  _All_ usages of "time zone" are confusing ;-)

This specific use pointed at something pretty trivial to state but
technical:  any instance of Python datetime arithmetic in which the
datetime input(s) and, possibly also the output, share the same tzinfo
member(s).  Specifically:

     datetime + timedelta
     datetime - timedelta
     datetime - datetime

Maybe another, but you get the idea.  Those all do "naive datetime
arithmetic", and in the last case the "same tzinfo member" part is
crucial (if the input datetimes have different tzinfo members in
subtraction, we're no longer "within a single time zone", and time
zone adjustments _are_ made:  it acts like both inputs are converted
to UTC before subtracting; but not so if both inputs share their
tzinfo members).

> As far as I can tell, you really mean "UTC offset". A time zone
> would be something like "Europe/London", which has two different
> UTC offsets throughout the year (not to mention other historical
> weirdnesses), whereas arithmetic on a "timezone-aware" datetime
>: is only going to work so long as you don't cross any of the
> boundaries where the UTC offset changes.

In this context I only had in mind tzinfo members.  They may represent
fixed-offset or multiple-offset "time zones" (or anything else a
programmer dreams up), or may even be None.  The datetime
implementation has no idea what they represent:  the implementation
can only judge whether two given tzinfo objects are or aren't the same
object.  So "within a single time zone" here just means there's only
one tzinfo object in play.

> I agree with you about pretty much everything else about datetime,
> just I find the terminology misleading. The only other thing I found
> really weird about datetime is how Python 2 had no implementation of
> a UTC tzinfo class, despite this being utterly trivial - but it's too
> late to do anything about that now, of course.

At the time, Guido ran his time machine forward, and saw that Stuart
Bishop would soon enough supply all the time zones known to mankind
;-)