[LEAPSECS] A standard for leap second smearing

[Richard Thomas]

On Sep 27, 2016, at 7:41 PM, Steve Summit <scs+ls at eskimo.com> wrote:

> Stephen Colebourne asked:
>> 2) When to smear?
>> Some smear up to midnight, some smear after midnight, some smear both
>> sides. What are the arguments for/against each?
> 
> I have a personal preference for smearing up to midnight.
> It just feels right to me that any shenanigans should be confined
> to the day that the leap second is at the end of, and that on the
> next day, everything is back to normal.

Remember that the leap second occurs at midnight UTC, not midnight your local timezone.
Does this change anything?
Does it matter that in Seattle the smear occurs at 5:00 in the afternoon, local time,
but in Melbourne, the smear occurs at 10:00 in the morning of the next day?

> 
>> 4) Anything else?
> 
> I think there are aspects of the implementation of any smearing
> that are maybe being glossed over.  I think it's important to
> distinguish pretty carefully between three distinct "clocks",
> or views of time:
> 1. The time exchanged between machines by a protocol such as NTP.
> 2. The time kept by an OS kernel (which is typically based on
>   oscillators that are disciplined by (1).)
> 3. The time returned to user-mode programs by system calls such
>   as gettimeofday.
> 
> There seems to be a presumption in several comments in this
> thread that (3) is necessarily identical to (2), but I think
> that's a bad idea.  If the suggestion is to implement smearing
> by temporarily messing with the actual kernel clock, I think
> you pretty inevitably end up with a complicated and bug-prone
> implementation.  Yet we should be striving for robust simplicity;
> indeed one of the arguments for abandoning leap seconds entirely
> is that the world seems to think that we computer geeks are
> incapable of implementing them correctly.
> 
> Moreover, carelessly messing with the actual kernel clock could
> mess up NTP's attempts to keep it disciplined.  (Indeed, as far
> as I know, ntpd's hardwired assumption is that (2) is always
> identical to (1), which tinkering with (2) would undermine.)
> 
> An alternative is to do the smearing purely mathematically,
> between (2) and (3), notionally as times are being handed to
> user mode by gettimeofday() and the like.  I don't believe it's
> necessary to tinker with internal clock steps or frequencies.
> 
> By analogy, I presume (though I don't know for sure) that
> Google's smear implementation is also a simple mathematical
> operation, performed in user mode by a modified NTP server,
> that's feeding smeared times to an isolated cluster of machines.
> Within that cluster, (1) == (2) == (3), they're all pure Posix,
> and there are no leap seconds.  Nowhere is there any explicit
> adjustment of any clock steps or frequencies.

This is far and away the easiest solution.
It only involves code changes in one place.
And we already have a good idea of what the code should look like,
because we have the “right” timezone family that converts between
UTC and TAI.

In fact, I’d go even further and suggest that the standard should require that (1) and (2) should be TAI, not UTC.  This could be done in a compatible way — perhaps with a flag in the NTP packets that says “if zero, the times herein are UTC; if one, the times are TAI.


> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs