[Python-Dev] PEP 418: Add monotonic clock

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