The planet is speeding up and a negative leap second may soon be needed | Hacker News Reader

The planet is speeding up and a negative leap second may soon be needed

jpost.com

12 pointsfortran7710 comments

What is needed is to lay off these leap seconds for a few centuries. Anybody who cares about the drift off TAI can keep track of it without messing up everyone else's lives.

Google's way of handling leap seconds is about the worst imaginable.

Fortunately there is a movement afoot to do that; and the leap second schedule for last June was cancelled, albeit probably not for that reason.

The way Google smears leap seconds seems very practical. I can't think of a time when I needed better than 1/86400 sec accuracy/precision. Being off by a second would be very noticeable. If you want/care, use a call that doesn't smear as that's the rarer requirement.

It means that during many hours the second is smeared out over, they are hundreds of milliseconds off of (almost) everybody else in the world -- in many cases even when others are also smearing. Since the only value in tracking a Standard time reference is to stay synchronized with others also following it, being hundreds of milliseconds off for hours on end is not much different from hours of downtime.

So then what I want is for everyone to smear the same way and stay in sync.

What you want, then, is a Standard. Smearing is decidedly non-Standard.

The Standard we have says to insert a leap second, or to be offline during the (short) period containing the leap second, if you can tolerate the downtime.

Standard is what's agreed upon, nothing more or less--standards change.

And, the best possible change would be to do away with leap seconds. Making everybody do the most complicated and difficult thing imaginable -- or choose between several of those, and have no correct choice -- would not be an improvement.

The number of applications that cannot tolerate two seconds' pre-scheduled downtime every other year, or one minute each century, is much lower than some people imagine. They will get that, but unscheduled, regardless.

The number of applications that need to be exactly synchronized to the astronomical position of the sun in the sky is even smaller. The number of those that would benefit from a more complicated time Standard is exactly zero.

I completely agree that leap seconds were a stupid idea to put into general purpose machines. From where we are though, consistent smearing seems the least disruptive, and long term doesn't suffer from drift. Having a mix of machines that respect/ignore leap seconds could accumulate to more than 1 sec differences.

As it is I know of at least three completely different smearing regimes, all incompatible with one another and extremely complicated to implement.

One thing is certain: anything complicated and difficult to implement will, in a large fraction of systems, not be implemented, or be implemented incorrectly, leading to needless hundreds-of-milliseconds disagreements between systems about what time it is.

Drift is absolutely harmless almost everywhere, and easy to correct for in the rare, isolated cases where it is not. The only cases I know of where it matters involve spacecraft, and those certainly are not using UTC internally.

Leap seconds adjust clocks which are run at an atomic standardized rate to meet the astronomical reality and keep UTC in sync. So far there have be 18 seconds of correction. Leap seconds are a bad idea. They confuse geophysical data. The interval of time between two measurements is not the difference between the clock values when the measurements were made.

Reply on news.ycombinator.com