[Python-Dev] PEP 418: Add monotonic clock

[Victor Stinner]

>>  * 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.try_monotonic()".
>
> 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