On 2012-03-28, at 10:45 AM, Nick Coghlan wrote: > On Thu, Mar 29, 2012 at 12:27 AM, Yury Selivanov > <yselivanov...@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.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 still don't like this 'emulation' idea. Smells bad for standard lib. Big -1 on this approach. - Yury _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
