[Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

[Guido van Rossum]

On Sat, Apr 7, 2012 at 6:26 PM, Raymond Hettinger
<raymond.hettinger at gmail.com> wrote:
> Just to clarify my previous post.
>
> It seems clear that benchmarking and timeout logic would benefit from a clock that cannot be adjusted by NTP.
>
> I'm unclear on whether time.sleep() will be based on the same clock so that timeouts and sleeps are on the same basis.

I made the same suggestion earlier but I don't know that anyone did
anything with it. :-( It would be nice to know what clock sleep() uses
on each of the major platforms.

> For scheduling logic (such as the sched module), I would think that NTP adjusted time would be what you want.

In my view, it depends on whether you are scheduling far in the future
(presumably guided by a calendar) or a short time ahead (milliseconds
to hours).

> I'm also unclear on the interactions between components implemented with different clocks
> (for example, if my logs show three seconds between events and a 10-second time-out exception occurs, is that confusing)?

I don't think this is avoidable. The logs will always use time.time()
or a local time derived from it; but we've accepted that for
benchmarking, timeouts and short-interval scheduling, that's not a
good clock to use.

-- 
--Guido van Rossum (python.org/~guido)