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

Thu Mar 15 20:22:03 CET 2012

In article 
<EFE3877620384242A686D52278B7CCD3362609 at RKV-IT-EXCH104.ccp.ad.local>,
 KristjÃ¡n Valur JÃ³nsson <kristjan at ccpgames.com> wrote:
> What does "jumping forward" mean? That's what happens with every clock at 
> every time quantum. The only effect here is that this clock will be slightly 
> noisy, i.e. its precision becomes worse. On average it is still correct. 
> Look at the use cases for this function
> 1) to enable timeouts for certaing operations, like acquiring locks:
> 	Jumping backwards is bad, because that may cause infinite wait time. But 
> jumping forwards is ok, it may just mean that your lock times out a bit early
> 2) performance measurements:
> 	If you are running on a platform with a broken runtime clock, you are not 
> likely to be running performance measurements.
>> Really, I urge you to skip the "strict" keyword. It just adds confusion. 
> Instead, lets just give the best monotonic clock we can do which doesn"t move 
> backwards.
> Let's just provide a "practical" real time clock with high resolution that is 
> appropriate for providing timeout functionality and so won't jump backwards 
> for the next 20 years. Let's simply point out to people that it may not be 
> appropriate for high precision timings on old and obsolete hardware and be 
> done with it.

I agree. I prefer the name time.monotonic with no flags. It will suit 
most use cases. I think supplying truly steady time is a low level 
hardware function (e.g. buy a GPS timer card) with a driver.
-- Russell