<div dir="ltr"><div dir="ltr">On Fri, Nov 13, 2020 at 4:12 PM John Haxby <<a href="mailto:john.haxby@oracle.com">john.haxby@oracle.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If the wall clock time for the Unix Epoch is not the stroke of midnight -- it *moves*.   And it moves because a day is exactly 86400 seconds.  In the real world though there have been 27 (I think) days between the Posix Epoch and now where a day was 86401 seconds.<br>
<br>
If you use a right timezone on Linux then you have to live with minor but irritating problems with programs that implicitly assume the Posix day length.  For those applications that really don't work unless you're using a right/ timezone, that minor annoyance is a price worth paying.<br></blockquote><div><br></div><div>Most applications that are neither astronomical nor navigational find it convenient to treat the nominal time since epoch as</div><div>"86400 times the number of days since 1 January 1970 + the number of elapsed seconds in the current day." The reason for ignoring leap seconds is that a great many applications deal with *civil* dates and times in the future, and it is impossible to predict more than a year or two in advance when a leap second might occur. </div><div><br></div><div>As a practical matter, this definition causes clock anomalies when leap seconds do occur.  What a great many services, including Google, do with the discontinuity is to adopt a 'leap smear'. When a leap second is inserted, the system clock is allowed to run at some figure such as 99.99% of its correct speed, so that over the next 10,000 seconds (2h 46m 40s) the clock will again be synchronized. (A similar technique could deal with a 59-second minute, but this has never occurred). More recently, the time constant has been changed from 1/10000 to 1/86400, to provide greater interval accuracy at the expense of smearing the leap second over an entire day.</div><div><br></div><div>This technique provides for a clock that advances monotonically, can be synchronized among systems, and still keeps pace with civil time, at the disadvantage of having interval measurements correct only to plus or minus 0.01% while a smear is taking place. Since all systems with synchronized clocks smear at the same rate, this takes care of database synchronization even to sub-second precision, and is pretty much adequate for all human-facing times; only scientific and navigational applications that require more precision in intervals need worry about the leap seconds.</div><div><br></div><div>A POSIX system that doesn't use 'right' will, in fact, have this behaviour by default if NTP is running. An attempt to synchronize with a time source at a lower stratum will show that the system's clock is off by a second, and the phase-locked</div><div>loop will drift it to bring it back into synchronization.</div><div><br></div><div>The convenience of this technique for proleptic calculation of civil times, and the fact that it allows for precise synchronization of one system with another, was thought by the POSIX people to outweigh the disadvantage of briefly being up to one second (by an amount that can be determined by a relatively simple calculation) out of step with respect to the heavens, the atomic clocks and the GPS constellation.</div><div><br></div><div>Some more sophisticated proposals have made the smear follow a cosine function rather than a linear one, so that there is no discontinuity in the rate at which the clock is ticking, as well as no discontinuity in the clock's reading</div><div><br></div><div><br></div><div>This scheme has been proposed formally a number of times, without committee action:</div><div><br></div><div>Original proposal: <a href="https://tools.ietf.org/html/draft-kuhn-leapsecond-00">https://tools.ietf.org/html/draft-kuhn-leapsecond-00</a></div><div>UTC-SLS (linear smearing with 1000 second time constant _before_ the leap second): <a href="https://www.cl.cam.ac.uk/~mgk25/time/utc-sls/">https://www.cl.cam.ac.uk/~mgk25/time/utc-sls/</a></div><div>Tcl programming language, 2000 (1000 second time constant, _after_ the leap second): <a href="https://core.tcl-lang.org/tips/doc/trunk/tip/7.md">https://core.tcl-lang.org/tips/doc/trunk/tip/7.md</a></div><div>Google 2008 (cosine smear, 20 hour time constant, before the leap second): <a href="https://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html">https://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html</a></div><div>Google 2012, 2015, 2016 (20 hour linear smear, centered on the leap second): <a href="https://cloudplatform.googleblog.com/2015/05/Got-a-second-A-leap-second-that-is-Be-ready-for-June-30th.html">https://cloudplatform.googleblog.com/2015/05/Got-a-second-A-leap-second-that-is-Be-ready-for-June-30th.html</a></div><div>Google's current implementation: <a href="https://developers.google.com/time/smear">https://developers.google.com/time/smear</a></div><div>Bloomberg smear (2000 second linear smear, after the leap second, widely used in the financial industry): <a href="https://data.bloomberglp.com/professional/sites/4/Bloomberg-Leap-Second_December-2016.pdf">https://data.bloomberglp.com/professional/sites/4/Bloomberg-Leap-Second_December-2016.pdf</a></div><div>Meinberg Funkuhren smear (configurable, used on several models of NTP primary clocks): <a href="https://www.meinbergglobal.com/download/burnicki/Leap%20Second%20Smearing%20With%20NTP.pdf">https://www.meinbergglobal.com/download/burnicki/Leap%20Second%20Smearing%20With%20NTP.pdf</a></div><div><br></div><div>Given that both the Meinberg and Google libraries can recover TAI from smeared 'seconds from the Epoch', the pull for 'right' time has very much lessened in the couple of decades that it's been around.</div><div><br></div><div><br></div><div>-- </div></div><div dir="ltr" class="gmail_signature">73 de ke9tv/2, Kevin</div></div>