[LEAPSECS] private smear goes public

[Warner Losh]

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.

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. 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 (though there are sources of
data on the internet that are changing that if you are connected.
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. Unlike
leap days, this is far from a solved problem.

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.

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