<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 7, 2012, at 3:08 AM, Paul Moore wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Use cases:<br><br>Display the current time to a human (e.g. display a calendar or draw a<br>wall clock): use system clock, i.e. time.time() or<br>datetime.datetime.now().<br>Event scheduler, timeout: time.monotonic().<br>Benchmark, profiling: time.clock() on Windows, time.monotonic(), or<br>fallback to time.time()<br></span></blockquote></div><div><br></div><div>ISTM, an event scheduler should use time.time().</div><div>If I schedule an event at 9:30am exactly, I really</div><div>want my system time to be one that is used.</div><div>Stock traders, for example, need to initiate event based</div><div>on scheduled times (i.e. the market opening and closing times).</div><div><br></div><div>With respect to benchmarking, the important attribute of time keeping</div><div>is that the start and end times be computed from the same offset.</div><div>For that purpose, I would want a clock that wasn't subject to adjustment at all,</div><div>or if it did adjust, do so in a way that doesn't hide the fact (i.e. spreading-out</div><div>the adjustment over a number of ticks or freezing time until a negative </div><div>adjustment had caught-up).</div><div><br></div><div>Then, there are timeouts, a common use-case where I'm not clear on the </div><div>relative merits of the different clocks. Which is the recommended clock</div><div>for code like this?</div><div><br></div><div> start = time.time()</div><div> while event_not_occurred():</div><div> if time.time() - start >= timeout:</div><div> raise TimeOutException</div><div><br></div><div>Ideally, the clock used here shouldn't get adjusted during the timing.</div><div>Failing that, the system time (plain old time.time()) seems like a reasonable</div><div>choice (I'm not used to seeing the system time just around at an irregular pace). </div><div><br></div><div>If time gets set backwards, it is possible to add code to defend against that as long as</div><div>the clock doesn't try to hide that time went backwards:</div><div><br></div><div><div> start = time.time()</div><div> while event_not_occurred():</div><div> now = time.time()</div><div> if now < start:</div><div> # time went backwards, so restart the countdown</div><div> start = now</div><div> if now - start >= timeout:</div><div> raise TimeOutException</div><div><br></div></div><div>If the new clocks go in (or rather stay in), there should be some clear recommendations</div><div>about which ones to use for various use cases. Those recommendations need to be</div><div>explained (i.e. under what circumstance would timeout code be better if one abandoned</div><div>time.time() in favor of one of the new clocks).</div><div><br></div><div>I ask this because adding multiple clocks WILL cause some confusion.</div><div>There will be cases where different tools use different clocks, resulting in unexpected interactions.</div><div>Victor is proposing that almost every use of time.time() in the standard library be replaced by</div><div>monotonic, but I'm at a loss to explain whether the code would actually be better off</div><div>or to explain in what circumstances the new code would behave differently in any observable way.</div><div><br></div><div>AFAICT, there has never been a reported bug in sched or Queue because they used time.time(),</div><div>so I'm reluctant to have those changed without very clear understanding of how the code would</div><div>be better (i.e. what negative outcome would be avoided with time.monotonic or somesuch).</div><div><br></div><div><br></div><div>Raymond</div><div><br></div><br></body></html>