Tim Peters added the comment:
[MvL]
> A. t1=t2=1385161652120375500
> B. pygettimeofday truncates this to 1385161652.120375
> C. time.time() converts this to float, yielding
> 0x1.4a3f8ed07b439p+30 i.e.
> (0.6450161580556887, 31)
> 1385161652.120375 (really .1203749566283776)
> D. _PyTime_ObjectToDenominator converts this to
> 1385161652.120374917
> E. time_t_to_FILE_TIME convert this to
> 1385161652.120374900
Got it. It's not surprising we can't round-trip, but it's annoying we can't
always round-trip even if there are no nanoseconds to lose at the start :-(
The only part here that rounds is step C - everything else truncates.
For example, start with 1385161652120374000. B is exact then, returning
seconds 1385161652 and usecs 120374.
C doesn't do _much_ damage, returning
1385161652.120374 == 0x1.4a3f8ed07b435p+30
D. breaks that into
1385161652.0
and
0.12037396430969238
yielding seconds 1385161652 and numerator 120373964. The last part is a little
truncated, but the major loss comes in E, which chops off the final "64" - we
end up changing
1385161652120374000 into
1385161652120373900
There's a reason C's time_t is almost always implemented as an integer type ;-)
I expect we'd be better off if we represented times internally as 64-bit ints,
used double for the output of time.time(), and refused to accept doubles for
any purpose - LOL ;-)
----------
status: pending -> open
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue19715>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
