[Mark Lawrence <breamore...@yahoo.co.uk>] > To me a day is precisely 24 hours, no more, no less. I have no interest in > messing about with daylight savings of 30 minutes, one hour, two hours or > any other variant that I've not heard about. > > In my mission critical code, which I use to predict my cashflow, I use code > such as. > > timedelta(days=14) > > Is somebody now going to tell me that this isn't actually two weeks?
Precisely define what "two weeks" means, and then someone can answer. The timedelta in question represents precisely 14 24-hours days, and ignores the possibility that some day in there may suffer a leap second. If you add that timedelta to a datetime object, the result may not be exactly 14*24 hours in the future as measured by civil time (which includes things like DST transitions). The result will have the same local time on the same day of the week two weeks forward. For example, if you started with Monday the 6th at 3:45pm, the result will be Monday the 20th at 3:45;pm. Period. The time zone (if any is attached) is wholly ignored throughout. If a DST transition occurs across that period, then it's impossible to say how far removed (as measured by. say, an independent stopwatch) Monday the 20th at 3:45pm is from Monday the 6th at 3:45pm without also knowing the month, the year, and the exact local time zone rules in effect across the period. It remains unclear to me which of those outcomes _you_ consider to be "actually 14 days". But my bet is that you like what Python already does here (because "tz-naive arithmetic" is exactly what _I_ want in all my financial code). _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
