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 vxgmichel
Recipients vxgmichel
Date 2020-01-29.13:02:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
On windows, the timestamps produced by time.time() often end up being equal because of the 15 ms resolution:

    >>> time.time(), time.time()
    (1580301469.6875124, 1580301469.6875124)

The problem I noticed is that a value produced by time_ns() might end up being higher then a value produced time() even though time_ns() was called before:

    >>> a, b = time.time_ns(), time.time()
    >>> a, b
    (1580301619906185300, 1580301619.9061852)
    >>> a / 10**9 <= b

This break in causality can lead to very obscure bugs since timestamps are often compared to one another. Note that those timestamps can also come from non-python sources, i.e a C program using `GetSystemTimeAsFileTime`.

This problem seems to be related to the conversion `_PyTime_AsSecondsDouble`:

    # Float produced by `time.time()`
    >>> b.hex()
    # Basically what `_PyTime_AsSecondsDouble` does:
    >>> (float(a) / 10**9).hex()
    # What I would expect from `time.time()`
    >>> (a / 10**9).hex()

However I don't know if this would be enough to fix all causality issues since, as Tim Peters noted in another thread:

> Just noting for the record that a C double (time.time() result) isn't quite enough to hold a full-precision Windows time regardless

Date User Action Args
2020-01-29 13:02:45vxgmichelsetrecipients: + vxgmichel
2020-01-29 13:02:45vxgmichelsetmessageid: <>
2020-01-29 13:02:45vxgmichellinkissue39484 messages
2020-01-29 13:02:45vxgmichelcreate