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

Nick Coghlan ncoghlan at gmail.com
Wed Mar 28 16:45:04 CEST 2012

On Thu, Mar 29, 2012 at 12:27 AM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:

What if system time jumps 1 year back?  We'll have the same monotonic time returned for this whole year?

I don't think we should even try to emulate any of OS-level functionality.

You have to keep in mind the alternative here: falling back to an unconditioned time.time() value (which is the status quo, and necessary to preserve backwards compatibility). That will break just as badly in that scenario and is precisely the reason that the OS level monotonic functionality is desirable in the first place.

I'd be quite happy with a solution that made the OS level monotonic clock part of the public API, with the caveat that it may not be available. Then the necessary trio of functions would be:

time.time(): existing system clock, always available time.os_monotonic(): OS level monotonic clock, not always available time.monotonic(): always available, same as os_monotonic if it exists, otherwise uses a time() based emulation that may not be consistent across processes and may "mark time" for extended periods if the underlying OS clock is forced to jump back a long way.

I think that naming scheme is more elegant than using monotonic() for the OS level monotonicity and try_monotonic() for the fallback version, but I'd be OK with the latter approach, too.

Regards, Nick.

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list