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 larry
Recipients larry, serhiy.storchaka, vstinner, vxgmichel
Date 2020-02-01.01:17:49
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1580519869.55.0.195288796897.issue39484@roundup.psfhosted.org>
In-reply-to
Content
I don't think this is fixable, because it's not exactly a bug.  The problem is we're running out of bits.  In converting the time around, we've lost some precision.  So the times that come out of time.time() and time.time_ns() should not be considered directly comparable.

Both functions, time.time() and time.time_ns(), call the same underlying function to get the current time.  That function is_PyTime_GetSystemClock(); it returns nanoseconds since the 1970 epoch, stored in an int64.  Each function then simply converts that time into its return format and returns that.

In the case of time.time_ns(), it loses no precision whatsoever.  In the case of time.time(), it (usually) converts to double and divides by 1e9, which is implicitly floor rounding.

Back-of-the-envelope math here: An IEEE double has 53 bits of resolution for the mantissa, not counting the leading 1. The current time in seconds since the 1970 epoch uses about 29 bits of those 53 bits.  That leaves 24 bits for the fractional second.  But you'd need 30 bits to render all one billion fractional values.  We're six bits short.

Unless anybody has an amazing suggestion about how to ameliorate this situation, I think we should close this as wontfix.
History
Date User Action Args
2020-02-01 01:17:49larrysetrecipients: + larry, vstinner, serhiy.storchaka, vxgmichel
2020-02-01 01:17:49larrysetmessageid: <1580519869.55.0.195288796897.issue39484@roundup.psfhosted.org>
2020-02-01 01:17:49larrylinkissue39484 messages
2020-02-01 01:17:49larrycreate