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 vstinner
Recipients larry, serhiy.storchaka, vstinner, vxgmichel
Date 2020-02-01.01:10:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1580519445.11.0.282787732766.issue39484@roundup.psfhosted.org>
In-reply-to
Content
Another way to understand the problem: nanosecond (int) => seconds (float) => nanoseconds (int) roundtrip looses precison.

>>> a=1580301619906185300
>>> a/1e9*1e9
1.5803016199061852e+18
>>> b=int(a/1e9*1e9)
>>> b
1580301619906185216
>>> a - b
84

The best would be to add a round parameter to _PyTime_AsSecondsDouble(), but I'm not sure how to implement it.

The following rounding mode is used to read a clock:

    /* Round towards minus infinity (-inf).
       For example, used to read a clock. */
    _PyTime_ROUND_FLOOR=0,

_PyTime_ROUND_FLOOR is used in time.clock_settime(), time.gmtime(), time.localtime() and time.ctime() functions: to round input arguments.

time.time(), time.monotonic() and time.perf_counter() converts _PyTime_t to float using _PyTime_AsSecondsDouble() (which currently has no round parameter) for their output.

See also my rejected PEP 410 ;-)

--

One way to solve this issue is to document how to compare time.time() and time.time_ns() timestamps in a reliable way.
History
Date User Action Args
2020-02-01 01:10:45vstinnersetrecipients: + vstinner, larry, serhiy.storchaka, vxgmichel
2020-02-01 01:10:45vstinnersetmessageid: <1580519445.11.0.282787732766.issue39484@roundup.psfhosted.org>
2020-02-01 01:10:45vstinnerlinkissue39484 messages
2020-02-01 01:10:44vstinnercreate