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 <1424900752.01.0.0421189480583.issue23521@psf.upfronthosting.co.za>
In-reply-to
Content
> 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)
611230

but

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


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)
Decimal('0.61122949999999998116351207499974407255649566650390625')

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.
History
Date User Action Args
2015-02-25 21:45:52belopolskysetrecipients: + belopolsky, mark.dickinson, benjamin.peterson, serhiy.storchaka, bdkearns
2015-02-25 21:45:52belopolskysetmessageid: <1424900752.01.0.0421189480583.issue23521@psf.upfronthosting.co.za>
2015-02-25 21:45:51belopolskylinkissue23521 messages
2015-02-25 21:45:51belopolskycreate