STINNER Victor added the comment: > C implementation of datetime.now() does not rely on float time, so this is > only an issue for the Python implementation.
Ah yes, but there is another technical issue that I'm trying to address in the issue #22117: datetime.datetime.now() is implemented with _PyTime_gettimeofday() which has a resolution of 1 microsecond, even it is now implemented with clock_gettime(CLOCK_REALTIME) which has a resolution of 1 nanoecond. On Linux, the effictive resolution of clock_gettime(CLOCK_REALTIME) is better than 1 microsecond, around 1/4 microsecond (250 nanosecond). > Overall, the proposed type is much less convenient than integer nanoseconds > because it does not support arithmetics. I'm working on using a number of nanoseconds using an integer type. It's just a signed 64-bit bit integer. If we decide to support nanosecond resolution in Python, a integer number of nanosecond may be enough. But this issue looks like the PEP 410 which was rejected. If you are motivated enough, you may update the PEP and write a new one. But first, read again the PEP and the discussion explaining why it was rejected. Basically, the loss of precision is very rare (or may not occur) in practice and the PEP 410 required to modify a lot of functions. Remember that the effictive resolution of time.time() on Windows is just 1 millisecond (0.001 second)... See the PEP 418 for many numbers, list of hardware clocks, operating system, etc. https://www.python.org/dev/peps/pep-0418/#system-time ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23084> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
