On Tue, Jun 1, 2010 at 1:44 PM, MRAB
but
datetime(1985, 6, 30, 23, 59, 60) - datetime(1985, 7, 1, 0, 0, 0)
datetime.timedelta(0)
Actually, that's wrong because there was a leap second. The clock went:
1985-06-30 23:59:59 1985-06-30 23:59:60 1985-07-01 00:00:00
The following year, however, it went:
1986-06-30 23:59:59 1986-07-01 00:00:00
It is only wrong if you expect datetime difference to reflect the actual duration between the corresponding UTC events. The datetime library does not do it even for dates. For example, on my system
date(1752, 9, 14) - date(1752, 9, 2) datetime.timedelta(12)
even though calendar application on the same machine shows that September 14 was the day after September 2 in 1752. $ cal 9 1752 September 1752 Su Mo Tu We Th Fr Sa 1 2 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 This was a deliberate design choice to implement proleptic calendar rather than a historically more accurate variant. Similarly I see nothing wrong with datetime difference not capturing leap seconds. An application interested in leap seconds effects, however should still be able to use the basic datetime object and define its own duration functions.