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).