[LEAPSECS] A standard for leap second smearing

[Joseph Gwinn]

On Tue, 27 Sep 2016 23:45:18 +0100, Stephen Colebourne wrote:
> Leap second smearing is a way of taking UTC (with leap seconds) and
> mapping it to a view of time that always has 86400 subdivisions per
> day.
> 
> Tony Finch summarized five known approaches, which are all linear:
> 
> Amazon    -12h +12h
> Bloomberg -0   +2ks
> Google    -10h +10h
> QTnet -"about 2 hours" +0
> UTC-SLS   -1ks +0
> 
> The goal of this thread is to see if consensus could be found for one
> approach of smearing.
> 
> The decisions would appear to be:
> 
> 1) Linear or Other?
> All current known smears are linear. Google previously had a different
> approach, but changed to linear. Are there any major arguments against
> linear? It would seem to be easier to specify and code that way.
> 
> 2) When to smear?
> Some smear up to midnight, some smear after midnight, some smear both
> sides. What are the arguments for/against each?
> 
> 3) Speed of smearing?
> The existing approaches have two broad groups - fast (under an hour -
> Bloomberg/UTC-SLS) and slow (20 hours or more - Google/Amazon) with
> QTnet an outlier towards the fast end. What are the arguments
> for/against fast/slow? Would there be a case for two agreed standards,
> one fast and one slow?
> 
> 4) Anything else?

In my experience, large systems that really care to avoid leap-second 
disruptions lock NTP to GPS System Time (not UTC) from the GPS 
receiver, and handle the leap-second offset in application code at the 
human interfaces and computer interfaces to external systems that 
understand only UTC.  

What's coming, due to IEEE 1588 PTP is that GPS receivers now have the 
ability to publish TAI (over the screaming objections of BIPM) as well, 
so many newer systems will lock NTP to TAI.

In both cases, there is usually a parallel all-hardware path that 
distributes nanosecond-accurate time from the GPS receiver to all 
time-critical hardware.

There is also usually another parallel all-hardware path distributing 
microsecond-accurate time.  This path was traditionally implemented 
using IRIG-B AM over coax, but now IEEE 1588 PTP is trying to take that 
niche over, but this will require increased maturity.

Joe Gwinn