[Python-Dev] Status on PEP-431 Timezones

[Stephen J. Turnbull]

Terry Reedy writes:
 > On 7/27/2015 11:21 AM, MRAB wrote:
 > 
 > > Also, if you "add one year" to 29 February 2016, what date do you get?
 > 
 > I believe the 'conventional' answer is 1 March 2017.  That is also 1 Mar 
 > 2016 + 1 year.  1 March 2017 - 1 year would be 1 Mar 2016.  Leap days 
 > get cheated.

I doubt there is a *single* "conventional" answer.  With respect to
*calendar* years, I suspect that more children born on February 29
celebrate their birthdays on February 28 than on March 1.

Another angle: I would imagine that a "real" conversation would go
something like "A: Let's meet one year from today."  "B: Today's the
29th, you know.  How about the 28th?"  If it wasn't mentioned, and one
arrived on the 28th, and another on the 1st, we'd consider that a
comedy, not one person's error of calculation according to
"conventional" rules.

I suspect that what you are calling "conventional" is actually due to
observing the cognitive bias called "substitution" (of a solvable
problem for an insoluble one).  That is, the problem of "computing the
date 1 timedelta year later" is substituted for the problem of
"computing the calendar date 1 year later".

But that's inappropriate, because these are two different use cases.
Calendar time is for coordination, such as birthday parties, and
timedelta time is for process control, such as venting nuclear
reactors.  Of course timedelta can be considered as a calendar by
assigning a place and an epoch, and it's convenient to assign one more
or less consistent with the "consensus calendar" in some "reasonable"
place.  Eg, UTC as a calendar is approximately the calendar in London.
But this is fundamentally arbitrary.  Consider the events that define
"Easter Sunday".

In this framework, I suppose one could characterize datetimes as
allowing "simple calculations with time intervals suitable for people
who don't hold meetings at 1:30am and who don't have birthdays or
wedding anniversaries on Feb 29, and are not separated from important
events by astronomical distances, nor likely to move at speeds greater
than 0.01% of the speed of light before the event happens".  Ie,
almost all of us almost all of the time.

I'm completely satisfied by Tim's answers and think "almost all" is
good enough for the stdlib for now.  If a separate module that
actually succeeds in eliminating the discrepancies between datetime
and calendar time as required by "coordinating process control time"
with human requirements for "simultaneous presence at meetings", I'd
be for including that calendar module in the stdlib, and deprecating
datetime.  But *elimination* is a high bar, and I think the stdlib
would have to be backward-compatible if it fails that criterion
(probably by including both modules).