<p>+1. I now prefer time.monotonic(), no flags. It attempts to be as high precision as possible and guarantees never to jump backwards. Russell's comment is right, the only steady sources are from hardware, and these are too equipment and operating system specific. (For this call anyway). </p>
<div class="gmail_quote">On Mar 16, 2012 3:23 AM, "Russell E. Owen" <<a href="mailto:rowen@uw.edu">rowen@uw.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In article<br>
<EFE3877620384242A686D52278B7CCD3362609@RKV-IT-EXCH104.ccp.ad.local>,<br>
Kristján Valur Jónsson <<a href="mailto:kristjan@ccpgames.com">kristjan@ccpgames.com</a>> wrote:<br>
<br>
> What does "jumping forward" mean? That's what happens with every clock at<br>
> every time quantum. The only effect here is that this clock will be slightly<br>
> noisy, i.e. its precision becomes worse. On average it is still correct.<br>
> Look at the use cases for this function<br>
> 1) to enable timeouts for certaing operations, like acquiring locks:<br>
> Jumping backwards is bad, because that may cause infinite wait time. But<br>
> jumping forwards is ok, it may just mean that your lock times out a bit early<br>
> 2) performance measurements:<br>
> If you are running on a platform with a broken runtime clock, you are not<br>
> likely to be running performance measurements.<br>
><br>
> Really, I urge you to skip the "strict" keyword. It just adds confusion.<br>
> Instead, lets just give the best monotonic clock we can do which doesn"t move<br>
> backwards.<br>
> Let's just provide a "practical" real time clock with high resolution that is<br>
> appropriate for providing timeout functionality and so won't jump backwards<br>
> for the next 20 years. Let's simply point out to people that it may not be<br>
> appropriate for high precision timings on old and obsolete hardware and be<br>
> done with it.<br>
<br>
I agree. I prefer the name time.monotonic with no flags. It will suit<br>
most use cases. I think supplying truly steady time is a low level<br>
hardware function (e.g. buy a GPS timer card) with a driver.<br>
<br>
-- Russell<br>
<br>
<br>_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com" target="_blank">http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com</a><br>
<br></blockquote></div>