homepage

I just noticed (while responding to issue 8643) that timedelta.total_seconds() has some accuracy problems, especially for negative timedeltas:
Python 3.2a0 (py3k:80840:80842, May 7 2010, 12:29:35) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import timedelta
>>> td = timedelta(microseconds = -123)
>>> td.total_seconds() # expect -0.000123
-0.0001230000052601099
This could be easily fixed by using integer arithmetic internally instead of float arithmetic:
>>> 1e-6 * td.microseconds + td.seconds + 86400 * td.days
-0.0001230000052601099
>>> (td.microseconds + 1000000 * (td.seconds + 86400 * td.days)) / 1000000
-0.000123
This works especially nicely in combination with the new float repr and the improved accuracy of true division in 2.7 / 3.2, to give a total_seconds() whose repr is free of noise digits. (Well, for small timedeltas, anyway.)
Since total_seconds is new in 2.7 and 3.2, I think it would be good to fix this before the 2.7 release.

P.S. This change would also make total_seconds() consistent with division by timedelta(seconds=1):
>>> td / timedelta(seconds=1)
-0.000123
In fact, this might even be a good way to re-implement total_seconds internally.

I am attaching a patch for py3k branch. I am +1 for backporting to 2.7 and I avoided relying on py3k timedelta/timedelta in the patch. The tests and docs will need to be modified for the backport.
Technically speaking, this is a change in documented behavior for 2.7 because according to current docs, td.total_seconds() is equivalent to ``td.microseconds / 1000000 + td.seconds + td.days * 24 * 3600``. Therefore I would appreciate if reviewer made a decision on backport.

Thanks for the patch! Comments, in increasing order of fussiness:
(1) there should be a Py_DECREF(total_microseconds) in the case that the "PyLong_FromLong(1000000L)" call fails
(2) in the docstring, replace 'loose' by 'lose'
(3) also in the docstring, I suggest replacing "280 years" by "270 years": "td == timedelta(seconds = td.total_seconds())" starts failing at 2**33 seconds (around 272.2 Julian years) rather than 2**53 microseconds.

Grr. s/docstring/docs/

> (1) there should be a Py_DECREF(total_microseconds) ...
Yes, regrtest -R is not a substitute for thinking.
> (2) in the docstring, replace 'loose' by 'lose'
>
Neither is spellcheck. :-)
> (3) also in the docstring, I suggest replacing "280 years" by "270 years" ...
Yes, and precision is not accuracy.

Looks good to me.
I definitely think this should go into 2.7 as well; total_seconds has only seen the light of day in the beta releases so far, so it's unlikely we'd break anyone's code with this change. (And IMO this is a bugfix, not a feature.)
It might be polite to wait a day or two for the 2.7 backport, though: 2.7 beta 2 is supposed to be being released today.

If you want a second (third?) opinion, we could ask Antoine.

[Antoine declines to offer an opinion.]
Committed to py3k in r80979. I moved the Misc/NEWS entry from the 'Library' section to the 'Extension Modules' section.
Leaving open for the 2.7 backport.

On Sat, May 8, 2010 at 10:07 AM, Mark Dickinson <report@bugs.python.org> wrote:
..
> I definitely think this should go into 2.7 as well; total_seconds has only seen the light of day
> in the beta releases so far, so it's unlikely we'd break anyone's code with this change.
> (And IMO this is a bugfix, not a feature.)
Tracker web site seems to be down, so I am trying my luck attaching a
patch to an e-mail reply. It did work in the past.
The true division by 10**6 could probably be replaced with division by
1e6 in the tests and docs, but I am not sure if the two are always
equivalent.

Perfect! Applied in r81020.
You're correct that n/10**6 and n/1e6 aren't the same thing, at least for n large enough:
Python 2.7b2+ (trunk:81019:81020, May 9 2010, 10:33:17) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import division
[35402 refs]
>>> (2**53+1)/10**6
9007199254.740993
[35404 refs]
>>> (2**53+1)/1e6
9007199254.740992
[35404 refs]
In the second case, 2**53+1 first gets converted to a float, and then the division is performed, so there are two points at which a rounding error can be introduced. The first case only involves one rounding error.