[Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
victor.stinner at gmail.com
Fri Apr 6 16:32:13 CEST 2012
> 2. Those who think that "monotonic clock" means a clock that never
> jumps, and that runs at a rate approximating the rate of real time.
> This is a very useful kind of clock to have! It is what C++ now calls
> a "steady clock". It is what all the major operating systems provide.
Python cannot give such guarantee. Extract of time.monotonic()
function proposed in the PEP 418:
"The elapsed time may or may not include time the system spends in
sleep or hibernation; this depends on the operating system."
The C++ Timeout Specification uses the following definition: "Objects
of class steady_clock represent clocks for which values of time_point
advance at a steady rate relative to real time. That is, the clock may
not be adjusted."
Proposed time.monotonic() doesn't respect this definition because
CLOCK_MONOTONIC *is* adjusted (slewed) on Linux.
We might provide a steady clock, but it would be less portable than
the monotonic clock. I'm not sure that we need such clock, which use
case requires a steady and not a monotonic clock? On Linux, I now
prefer to use CLOCK_MONOTONIC (monotonic) than CLOCK_MONOTONIC_RAW
(monotonic and steady as defined by C++) *because* its frequency is
More information about the Python-Dev