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

Yury Selivanov yselivanov.ml at gmail.com
Wed Mar 28 17:02:30 CEST 2012

On 2012-03-28, at 10:45 AM, Nick Coghlan wrote:

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.

Well, my argumentation is that you either have some code that depends on monotonic time and can't work without it, or you have a code that can work with any time (and only precision matters). Maybe I'm wrong.

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.osmonotonic(): OS level monotonic clock, not always available time.monotonic(): always available, same as osmonotonic 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 still don't like this 'emulation' idea. Smells bad for standard lib. Big -1 on this approach.

More information about the Python-Dev mailing list