[Python-Dev] PEP 418: rename time.monotonic() to time.steady()?

Victor Stinner victor.stinner at gmail.com
Tue Apr 3 13:26:12 CEST 2012


I would to rename time.monotonic() to time.steady() in the PEP 418 for
the following reasons:

 - time.steady() may fallback to the system clock which is not
monotonic, it's strange to have to check for
 - time.steady() uses GetTickCount() instead of
QueryPerformanceCounter() whereas both are monotonic, but
QueryPerformanceCounter() is not steady

Python steady clock will be different than the C++ definition.

You may argue that time.steady() is not always steady: it may fallback
to the system clock which is adjusted by NTP and can jump
backward/forward with a delta greater than 1 hour. In practice, there
is only one operating system that does not provide a monotonic clock:

I hesitate to add "is_steady" to time.get_clock_info(), but a boolean
is not very useful, it would be better to have a number.

Arguments for time.monotonic() name:

 - Users are looking for the "monotonic" name
 - Most of the time, time.monotonic() is a monotonic clock


On Linux, we might use CLOCK_MONOTONIC for time.steady() and
CLOCK_MONOTONIC_RAW for time.highres(). The NTP daemon Linux on Linux
uses a reliable clock to adjust CLOCK_MONOTONIC frequency and so
CLOCK_MONOTONIC is steady and it may go backward in a short period,
whereas CLOCK_MONOTONIC_RAW cannot go backward and so may fit closer
time.highres() requirements.

Currently, CLOCK_MONOTONIC is used for time.highres() and
time.steady() in the PEP.


NTP on Linux should only slew CLOCK_MONOTONIC, not step it. But it
looks like there was a bug in the Linux kernel 2.6.31: CLOCK_MONOTONIC
goes backward sometimes. Bug introduced in 2.6.31 by (August 14,
and fixed in the kernel 2.6.32 by (November 16, 2009):

Someone had the bug:

PS: I already changed time.monotonic() to time.steady() in the PEP :-p

More information about the Python-Dev mailing list