Alexander Belopolsky added the comment:
> 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.
----------
nosy: +mark.dickinson
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23521>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
