Message236623
> 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. |
|
Date |
User |
Action |
Args |
2015-02-25 21:45:52 | belopolsky | set | recipients:
+ belopolsky, mark.dickinson, benjamin.peterson, serhiy.storchaka, bdkearns |
2015-02-25 21:45:52 | belopolsky | set | messageid: <1424900752.01.0.0421189480583.issue23521@psf.upfronthosting.co.za> |
2015-02-25 21:45:51 | belopolsky | link | issue23521 messages |
2015-02-25 21:45:51 | belopolsky | create | |
|