[tz] What's "right"?

[Kevin Kenny]

On Fri, Nov 13, 2020 at 4:12 PM John Haxby <john.haxby at oracle.com> wrote:

> 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.
>
> 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.
>

Most applications that are neither astronomical nor navigational find it
convenient to treat the nominal time since epoch as
"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.

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.

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.

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
loop will drift it to bring it back into synchronization.

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.

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


This scheme has been proposed formally a number of times, without committee
action:

Original proposal: https://tools.ietf.org/html/draft-kuhn-leapsecond-00
UTC-SLS (linear smearing with 1000 second time constant _before_ the leap
second): https://www.cl.cam.ac.uk/~mgk25/time/utc-sls/
Tcl programming language, 2000 (1000 second time constant, _after_ the leap
second): https://core.tcl-lang.org/tips/doc/trunk/tip/7.md
Google 2008 (cosine smear, 20 hour time constant, before the leap second):
https://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html
Google 2012, 2015, 2016 (20 hour linear smear, centered on the leap
second):
https://cloudplatform.googleblog.com/2015/05/Got-a-second-A-leap-second-that-is-Be-ready-for-June-30th.html
Google's current implementation: https://developers.google.com/time/smear
Bloomberg smear (2000 second linear smear, after the leap second, widely
used in the financial industry):
https://data.bloomberglp.com/professional/sites/4/Bloomberg-Leap-Second_December-2016.pdf
Meinberg Funkuhren smear (configurable, used on several models of NTP
primary clocks):
https://www.meinbergglobal.com/download/burnicki/Leap%20Second%20Smearing%20With%20NTP.pdf

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.


-- 
73 de ke9tv/2, Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20201113/a8e49423/attachment.html>