> > [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. [Kevin] > 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/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4