[LEAPSECS] private smear goes public

Fri Dec 2 09:33:12 EST 2016

On 2016-12-02 12:57 AM, Warner Losh wrote:
> On Thu, Dec 1, 2016 at 6:49 PM, Brooks Harris <brooks at edlmax.com> wrote:
>> Hi Warner,
>>
>> On 2016-12-01 08:02 PM, Warner Losh wrote:
>>> On Thu, Dec 1, 2016 at 4:28 PM, Stephen Colebourne <scolebourne at joda.org>
>>> wrote:
>>>> On 1 December 2016 at 19:45, Brooks Harris <brooks at edlmax.com> wrote:
>>>>> As I read it I think Google's intention is to publish their method and
>>>>> algorithm in the hopes others may follow it. It would be better if
>>>>> everybody
>>>>> did it the same way, but it will remain to be seen if others will choose
>>>>> to
>>>>> follow the example.
>>>> The page reads clearly enough to me that:
>>>>
>>>> - Google will leap over 20 hours this time because it is too late to
>>>> change their plans
>>>> - They plan to leap over 24 hours next time to match Amazon and others
>>>> - The propose an informal "standard" of 24 hours leaps henceforth
>>>>
>>>> If all the big IT players agree on a 24 hour leap, 12 hours either
>>>> side of midnight UTC, then we have all moved a step forward. Even more
>>>> so if they write up the approach as a formal standard.
>>>>
>>>> The next issue is that there are then two types of NTP server -
>>>> smeared and non-smeared - and no way to tell the difference. Call me
>>>> naive, but that seems like a perfectly soluble problem, either within
>>>> NTP or external to it.
>>>>
>>>> For the record, I think that both leap-smeared and leap-accurate
>>>> broadcast time have value, but it should be easily possible to tell
>>>> which is being received. I also desperately want there to be a name
>>>> for the proposed informal standard, so we can all talk about it.
>>> I find the two different types of time amble evidence that leap
>>> seconds are evil and must die. Nobody knows what to do with them. Few
>>> get it right so we have to resort to tricks to pretend they aren't
>>> there. And people that care wind up disappointed that more things
>>> don't get them right. Clearly the bastard stepchild of time that
>>> should be relegated to the dustbin of history.
>> I'm sure you know I'm on the other side of that opinion; that UTC with Leap
>> Seconds is a very good, even brilliant, solution to the inconvenient fact of
>> the Earth's wobbly rotation to preserve the age old tradition of timekeeping
>> by the sun. This in the same way Gregorian calendar 'solved' the length of
>> the year.
> If it was solved in the same way that the Gregorian Calendar solved
> the leap year problem, everybody would get it right. Leap days aren't
> a big deal because there's a tiny bit of math that I can do and get it
> right every time. I can get the math wrong and still be right for the
> next 84 years if I don't know all the rules. The Gregorian Calendar,
> though a bit complex, is 100% predictable. I know there will be a Feb
> 29, 2020, and there won't be a Feb 29, 2021. And I don't need an
> internet connection or other data stream to know that.
Sure. I meant only that Gregorian makes an adjustment to the calendar 
counting scheme to keep it aligned to the sun and moon, while Leap 
Seconds makes a much smaller, irregular, adjustment for similar reasons.
>
> Leap seconds are unlike this because they are irregular. They come and
> go at the when of the earth's rotation and a bureaucrat's whim.
Well, it seems much more organized than a "whim" to me. An awful lot of 
work by many organizations goes into the IERS's decisions about Leap 
Seconds.
> They
> aren't regular. You have to know and be in the loop or you'll get them
> wrong. There's no formula to look up, no regular rule. There's no math
> that will save you. You have to wait for people to look out the window
> and hold their thumb in the air and say "it's time". That's another
> problem with leap seconds: they are irregular and there's no standard
> way to get the leap second info reliably
Oh yes. This seems like an obvious missing link to me. Its been 
discussed here many times.
> (though there are sources of
> data on the internet that are changing that if you are connected.
 From one point of view, too many. And they are not yet uniformly 
formatted nor officially backed up by IERS.

It seems to me IETF RFC 7808, Time Zone Data Distribution Service 
https://tools.ietf.org/html/rfc7808 is the closest thing to a promising 
standard, but its not yet been implemented as a service I know of. It 
seems to hold promise, but there are probably many steps toward formal 
standardization needed to assure the quality of the data before its 
really "official" and uniformly deployed.

> Since they are so irregular, nobody gets them right. They aren't
> generally included in discussions about time like leap days are. They
> are this weird little thing at the edge of UTC that makes it necessary
> to have the slewing solutions. Too few people know about how to cope
> with them, and the computer standards pretend they don't exist.
Right. Its going to be a very long migration path toward truly Leap 
Second compatible applications. Today there's no coherent plan to 
accomplish that end-to-end.
> Unlike
> leap days, this is far from a solved problem.
Yup. That's why LEAPSECS, I guess.
>
> I could go on at length for the reasons why. But I've ranted long enought....
>
>> But, regardless of our opinions, Leap Seconds are here to stay until at
>> least 2023 and probably much longer. So, "smear" is with us to protect the
>> 86400-second-day systems. There's no avoiding this, really, because those
>> systems have no hole into which the 86401th peg can be put. And, I might
>> add, who ever tested the systems end-to-end for a negative Leap Second?
> I did when I was working on them. But I'm sure most people don't. I
> know that leap seconds are with us for the foreseeable future. I don't
> have to like them.
Sure. I'm not sure I 'like' Leap Seconds any more than the calendar, 
both products of timekeeping tradition and the behavior of the universe. 
Its all deceptively complicated.  I like the science and technology 
applied for Leap Seconds by BIPM and IERS, but frustrated this doesn't 
yet translate to practical solutions for 'precise', or 'accurate',  
local timekeeping. I guess that's why I keep trying to work on it.

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