On Tue, Mar 13, 2012 at 6:10 PM, Nadeem Vawda <nadeem.va...@gmail.com> wrote: > On Wed, Mar 14, 2012 at 3:03 AM, Victor Stinner > <victor.stin...@gmail.com> wrote: >> I suppose that most libraries and programs will have to implement a >> similar fallback. >> >> We may merge both functions with a flag to be able to disable the >> fallback. Example: >> >> - time.realtime(): best-effort monotonic, with a fallback >> - time.realtime(monotonic=True): monotonic, may raise OSError or >> NotImplementedError > > This was my suggestion - I think it's useful to have the fallback > available (since most users will want it), but at the same time we > should also cater to users who need a clock that is *guaranteed* to > be monotonic. > > As an aside, I think "monotonic" is a better name than "realtime"; > it conveys the functions purpose more clearly. Then we could call > the flag "strict".
While you're bikeshedding: Some of the drafts of the new C++ standard had a monotonic_clock, which was guaranteed to only go forwards, but which could be affected by system clock updates that went forwards. Because of problems in defining timeouts using an adjustable clock, C++11 instead defines a "steady_clock", which ticks as steadily as the machine/OS/library can ensure, and is definitely not affected by any time adjustments: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.htm. I realize that Unix's clock_gettime(CLOCK_MONOTONIC) already includes the steadiness criterion, but the word itself doesn't actually include the meaning. _______________________________________________ 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
