[New-bugs-announce] [issue39484] time_ns() and time() cannot be compared on windows

[Vincent Michel]

New submission from Vincent Michel <vxgmichel at gmail.com>:

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
    False

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`:
https://github.com/python/cpython/blob/f1c19031fd5f4cf6faad539e30796b42954527db/Python/pytime.c#L460-L461

    # Float produced by `time.time()`
    >>> b.hex()
    '0x1.78c5f4cf9fef0p+30'
    # Basically what `_PyTime_AsSecondsDouble` does:
    >>> (float(a) / 10**9).hex()
    '0x1.78c5f4cf9fef0p+30'
    # What I would expect from `time.time()`
    >>> (a / 10**9).hex()
    '0x1.78c5f4cf9fef1p+30'

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

(https://bugs.python.org/issue19738#msg204112)

----------
components: Library (Lib)
messages: 360958
nosy: vxgmichel
priority: normal
severity: normal
status: open
title: time_ns() and time() cannot be compared on windows
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________