This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients belopolsky, mark.dickinson, mcherm, rhettinger, stutzbach, tim.peters, vstinner
Date 2010-06-25.14:41:26
SpamBayes Score 0.020008953
Marked as misclassified No
Message-id <1277476888.53.0.239622209471.issue8860@psf.upfronthosting.co.za>
In-reply-to
Content
>> The timedelta(seconds=0.6112295) example is handled correctly

> No, it's not!  It's being rounded *up* where it should be
> being rounded *down*.

Let me try to reformulate the issue.  When use is entering 0.6112295, she means 0.6112295, not 0x1.38f312b1b36bdp-1 or 0.61122949999999998116351207499974407255649566650390625 which are exact values of the underlying binary representation of 0.6112295.  Modern Python is able to round 0.6112295 to 6 decimal places correctly:

>>> round(0.6112295, 6)
0.611229

and timedelta should do the same, but it does not:

>>> timedelta(seconds=0.6112295)
datetime.timedelta(0, 0, 611230)

With respect to accumulation, I believe the invariant that we want to have should be

timedelta(x=a, y=b, ...) == timedelta(x=a) + timedelta(y=b)

while the alternative (using higher precision addition with rounding at the end) may be more accurate in some cases, the above looks least surprising.
History
Date User Action Args
2010-06-25 14:41:28belopolskysetrecipients: + belopolsky, tim.peters, mcherm, rhettinger, mark.dickinson, vstinner, stutzbach
2010-06-25 14:41:28belopolskysetmessageid: <1277476888.53.0.239622209471.issue8860@psf.upfronthosting.co.za>
2010-06-25 14:41:27belopolskylinkissue8860 messages
2010-06-25 14:41:26belopolskycreate