New submission from Vincent Michel <vxgmic...@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 <rep...@bugs.python.org> <https://bugs.python.org/issue39484> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com