On 27 Jul 2015, at 04:04, Tim Peters email@example.com wrote:
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.
There was a long list of use cases coming to the same conclusion. The current arithmetic allows uniform patterns in local time to be coded in uniform, straightforward ways. Indeed, in "the obvious" ways. The alternative behavior favors uniform patterns in UTC, but who cares? ;-) Few local clocks show UTC. Trying to code uniform local-time behaviors using "aware arithmetic" (which is uniform in UTC. but may be "lumpy" in local time) can be a nightmare.
The canonical counterexample is a nuclear reactor that needs to be vented every 24 hours. To which the canonical rejoinder is that the programmer in charge of that system is criminally incompetent if they're using _any_ notion of time other than UTC ;-)
IMHO “+ 1 days” and “+ 24 hours” are two different things. Date arithmetic is full of messy things like that. “+ 1 month” is another example of that (which the datetime module punts completely and can be a source of endless bikeshidding).