[Python-Dev] (time) PEP 418 glossary V2

Victor Stinner victor.stinner at gmail.com
Tue Apr 24 18:35:45 CEST 2012

>> I don't know any monotonic with a defined epoch or
>> mappable to the civil time.
> The very basic "seconds (not even milliseconds) since the beginning of
> 1970" fits that definition, but doesn't seem to fit what most people
> mean by "Monotonic Clock".
> I'm still a little fuzzy on *why* it shouldn't count as a monotonic
> clock.  Is it technically valid, but a lousy implementation because of
> insufficient precision or resolution?  Is it because the functions
> used in practice (on a modern OS) to retrieve timestamps don't
> guarantee to ignore changes to the system clock?

You mean the time() function? It is the system clock and the system
clock is not monotonic because it can jump backward. It is also
affected when... the system clock is changed :-)

> Looking at the first table there (Linux 3.3 with Intel Core i7-2600 at
> 3.40GHz (8 cores)), CLOCK_MONOTONIC can be hundreds of times slower
> than time(), and over 50 times slower than CLOCK_MONOTONIC_COARSE.  I
> would assume that CLOCK_MONOTONIC_COARSE meets the technical
> requirements for a monotonic clock, but does less well at meeting the
> actual expectations for some combination of
> (precision/stability/resolution).

bet that most people prefer a clock with an higher precision over a
faster clock. When the issue #14555 (Add more clock identifiers) will
be done, you will be able to call
time.clock_gettime(time.CLOCK_MONOTONIC_COARSE) in Python if you need
a faster monotonic clock.

>> CLOCK_MONOTONIC and CLOCK_REALTIME use the same hardware clocksource
>> and so have the same latency depending on the hardware.
> Is this a rule of thumb or a requirement of some standard?

It is how these clocks are implemented on Linux. I don't know how they
are implemented on other OSes. It was just to say that their
performance should be *very close* on Linux.

> Does that fact that Windows, Mac OS X, and GNU/Hurd don't support
> CLOCK_MONOTONIC indicate that there is a (perhaps informal?)
> specification that none of their clocks meet, or does it only indicate
> that they didn't like the name?

CLOCK_MONOTONIC requires the clock_gettime() function: clock_gettime()
is not available on Windows nor Mac OS X. For Hurd, see:

The PEP 418 uses other monotonic clocks for Windows and Mac OS X, but
GNU/Hurd is the only OS not supporting the new time.monotonic()


More information about the Python-Dev mailing list