[Python-Dev] PEP 418: Add monotonic clock (original) (raw)

Victor Stinner victor.stinner at gmail.com
Wed Mar 28 10:40:22 CEST 2012

 * time.time() = system clock  * time.monotonic() = monotonic clock  * time.hires() = monotonic clock or fallback to system clock

time.hires() definition is exactly what I was trying to implement with "time.steady(strict=True)" / "time.trymonotonic()". Please don't call the fallback version "hires" as it suggests it may be higher resolution than time.time() and that's completely the wrong idea.

Why would it be a wrong idea? On Windows, time.monotonic() frequency is at least 1 MHz (can be GHz if it uses your CPU TSC) whereas time.time() is only updated each millisecond at the best case (each 15 ms by default if I remember correctly).

On UNIX, CLOCK_MONOTONIC has the same theorical resolution than CLOCK_REALTIME (1 nanosecond thanks to the timespec structure) and I expect the same accuracy.

On Mac, I don't know if mach_absolute_time() is more or as accurate than time.time().

time.hires() uses time.monotonic() if available, so if time.monotonic() has an higher resolution than time.time(), time.hires() can also be called a high-resolution clock. In practice, time.monotonic() is available on all modern platforms.

If we're simplifying the idea to only promising a monotonic clock (i.e. will never go backwards within a given process, but may produce the same value for an indefinite period, and may jump forwards by arbitrarily large amounts),

I don't know any monotonic clock jumping "forwards by arbitrarily large amounts". Linux can change CLOCK_MONOTONIC speed, but NTP doesn't "jump".

then we're back to being able to enforce monotonicity even if the underlying clock jumps backwards due to system clock adjustments.

Do you know a monotonic clock that goes backward? If yes, Python might workaround the clock bug directly in time.monotonic(). But I would prefer to not workaround OS bugs.

Victor

More information about the Python-Dev mailing list