[Python-Dev] Drop the new time.wallclock() function? (original) (raw)

Paul Moore p.f.moore at gmail.com
Thu Mar 15 13:20:48 CET 2012

On 15 March 2012 12:12, Nadeem Vawda <nadeem.vawda at gmail.com> wrote:

On Thu, Mar 15, 2012 at 1:10 PM, Paul Moore <p.f.moore at gmail.com> wrote:

I appreciate that. But I'm still unclear how you would tell that had happened as part of the implementation. One call to the OS returns 12345. The next returns 13345. Is that because 100 ticks have passed, or because the clock "leapt forward"? With no point of reference, how can you tell? The point (AIUI) is that you can't identify such adjustments (in the absence of some sort of log of NTP updates), so we should provide a mechanism that is guaranteed not to be affected by them.

OK, I see (sort of). But if that is the case, what's the use case for the variation that is affected by them? The use cases I've seen mentioned are timeouts and performance testing, both of which don't want to see clock adjustments.

Note that when Victor started this thread, he said:

I prefer to keep only monotonic() because it is not affected by system clock update and should help to fix issues on NTP update in functions implementing a timeout.

which seems to me to be exactly this point. So I guess I support Victor's original proposal. (Which is good, because he has thought about this issue far more than I have :-))

Paul.

More information about the Python-Dev mailing list