Hi, On Mon, 16 Oct 2017 12:42:30 +0200 Victor Stinner <victor.stin...@gmail.com> wrote: > > ``time.time()`` returns seconds elapsed since the UNIX epoch: January > 1st, 1970. This function loses precision since May 1970 (47 years ago)::
This is a funny sentence. I doubt computers (Unix or not) had nanosecond clocks in May 1970. > This PEP adds five new functions to the ``time`` module: > > * ``time.clock_gettime_ns(clock_id)`` > * ``time.clock_settime_ns(clock_id, time: int)`` > * ``time.perf_counter_ns()`` > * ``time.monotonic_ns()`` > * ``time.time_ns()`` Why not ``time.process_time_ns()``? > Hardware clock with a resolution better than 1 nanosecond already > exists. For example, the frequency of a CPU TSC clock is the CPU base > frequency: the resolution is around 0.3 ns for a CPU running at 3 > GHz. Users who have access to such hardware and really need > sub-nanosecond resolution can easyly extend Python for their needs. Typo: easily. But how is easy is it? > Such rare use case don't justify to design the Python standard library > to support sub-nanosecond resolution. I suspect that assertion will be challenged at some point :-) Though I agree with the ease of implementation argument (about int64_t being wide enough for nanoseconds but not picoseconds). Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com