[Guido] Then I propose to remove the feature of automatic mixing int/long/float and datetime or timedelta instances in add/subtract operations. You'll have to specify what you want using a timedelta(days, seconds) constructor. That's clearer anyway.
I much prefer this. My own datetime object uses a syntax like this:
t = t + Delta(days=1,minutes=-5,seconds=5)
I'm considering such an extension to the timedelta() constructor too.
However, lets be clear; is t=t+1 adding 1 (calendar) day or 24 hours (86400 seconds)?
How does it differ? (We already ignore leap seconds.)
The concept of a "day" can be somewhat ambiguous. I've seen datetime implementations that will apply DST changes when asked to adjust by days, but not when asked to adjust by seconds, hours or minutes. So, in the general case of a DST aware datetime object,
t + Delta(days=1) != t + Delta(hours=24)
even when ignoring leap-seconds and other micro-adjustments. So lets define adjustments by "days" for the base datetime object in terms of 86400.0 seconds. A DST aware datetime subclass can then be made that does the more complex day-based arithmetic.
Yes. A "day" is always 24 hours.
--Guido van Rossum (home page: http://www.python.org/%7Eguido/)