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

[Paul Moore]

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.