On 2016-12-02 12:57 AM, Warner Losh wrote:
On Thu, Dec 1, 2016 at 6:49 PM, Brooks Harris <bro...@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 <scolebou...@joda.org>
wrote:
On 1 December 2016 at 19:45, Brooks Harris <bro...@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@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
