On Sat, Mar 31, 2012 at 7:37 PM, Victor Stinner
<victor.stin...@gmail.com> wrote:
>> If we provide a way to check if the monotonic clock is monotonic (or
>> not), I agree to drop the flag from time.monotonic(fallback=True) and
>> always fallback. I was never a fan of the "truly monotonic clock".
>>
>> time.clock_info('monotonic')['is_monotonic'] is a good candidate to
>> store this information.
>
> I updated the PEP to add time.get_clock_info() and to drop the
> fallback parameter of time.monotonic() (which now always falls back).
>
> Because "monotonic" word cannot define time.monotonic() anymore, I
> suggest to rename the time.monotonic() function to time.steady(). So
> we would have:
>
> - time.steady() may or may not be monotonic, but its is as steady as possible.
> - time.get_clock_info('steady')['is_monotonic'] which looks less
> surprising than time.get_clock_info('monotonic')['is_monotonic']
>
> It doesn't follow the C++ steady_clock definition, but it looks like
> the Boost library doesn't follow the C++ definition... (it uses
> CLOCK_MONOTONIC on Linux)
>
> By the way, it now prefer to use CLOCK_MONOTONIC instead of
> CLOCK_MONOTONIC_RAW on Linux. It is what I need in practice. If the
> hardware clock is a little bit too fast or too slow, NTP adjusts its
> rate so a delta of two timestamps is really a number of seconds. It's
> not yet written explicitly in the PEP, but the unit of
> time.monotonic/time.steady and time.highres is a second.

Hmm... I believe NTP can also slew the clock to deal with leap seconds
(which the POSIX standard requires must be ignored). That is, when a
leap second is inserted, the clock is supposed to stop value for one
second. What actually happens is that for some time around the leap
second (I've heard maybe a day), the clock is slowed down slightly.
I'm guessing that this affects CLOCK_MONOTONIC but not
CLOCK_MONOTONIC_RAW. Personally I'd rather use the latter -- if I want
to be synchronous with wall clock time, I can just use time.time().

-- 
--Guido van Rossum (python.org/~guido)
_______________________________________________
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

Reply via email to