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 bdkearns, belopolsky, benjamin.peterson, mark.dickinson, serhiy.storchaka
Date 2015-02-25.21:45:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> the bug in C implementation should be fixed.

In the past (see #8860) we were not able to reach a consensus on which behavior is correct and which has a bug:

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

It all boils down to the the fact that

>>> round(0.6112295*10**6)


>>> round(0.6112295, 6) * 10**6

In my view, timedelta(seconds=1) is 10**6 microseconds and timedelta(seconds=1) * 0.6112295 is 611229.5 microseconds which is correctly rounded to 611230 in  timedelta(seconds=0.6112295), but timedelta(seconds=1)*0.6112295 returning 611229 is incorrect.

If I understand Mark's argument correctly (see msg107097), he views timedeltas as fractional number of seconds rather than integer number of microseconds and in his view timedelta(seconds=0.6112295) is timedelta(seconds=0.6112295) is 0.611229499999999981 seconds because

>>> Decimal(0.6112295)

Thus timedelta(seconds=0.6112295), 0.6112295 should be rounded down to 6 decimal places and result in 611229 microseconds.

Neither of us thought resolving this was important enough to hold other fixes.  In the same spirit, I suggest that we apply my current patch that fixes a crash and pass the rounding curiosity down to the future generations.
Date User Action Args
2015-02-25 21:45:52belopolskysetrecipients: + belopolsky, mark.dickinson, benjamin.peterson, serhiy.storchaka, bdkearns
2015-02-25 21:45:52belopolskysetmessageid: <>
2015-02-25 21:45:51belopolskylinkissue23521 messages
2015-02-25 21:45:51belopolskycreate