[ntp:questions] Leap second to be introduced in June

Terje Mathisen terje.mathisen at tmsw.no
Tue Jan 13 08:33:05 UTC 2015


Brian Utterback wrote:
> On 1/12/2015 6:29 AM, Mike Cook wrote:
>>>> Not true. That would violate POSIX. There is no "properly implements",
>>>> or "right thing".
>>> Perhaps you're unaware that POSIX isn't the One True Operating System
>>> specification.
>>>
>>> "Properly implements" means it follows the well defined, 40 year old
>>> normative specification for handling leap seconds, which requires
>>> supporting minutes with 59 or 61 seconds. That's something POSIX
>>> doesn't properly implement.
>> Agreed. It is often overlooked that leap seconds were implemented from
>> 1972 and POSIX only  saw the light of day in 1988. So POSIX is just
>> plain wrong here IMHO.
>>
>
> Of course I am aware that POSIX isn't the one true operating system
> specification. But it certainly is a specification. And for a very large
> number of people in the world, POSIX conformity is more important than
> the UTC specification. I agree that POSIX was wrong, but it is what it
> is. What is the "right thing to do" if you have two conflicting standards?

I hate to admit it, but I'm starting to believe Google's approach, where 
they smear the leap second over something like a day, might be one of 
the better workarounds.

It means that any sort of timing done during this time period will be 
off by the smear ratio/frequency offset, i.e. on the order of 1.5e-5 or so.

Even for benchmarking runs an error of this magnitude will be down in 
the noise, the remaining problems are for stuff like telescope control.

For distributed logging you have to use the same method for every single 
node, but that is the case today as well. :-(

I.e. with one domain smearing and another stepping, the times between 
them will be skewed over the entire smearing period.

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"



More information about the questions mailing list