Steve Allen

Leapseconds are inserted to keep UTC within ±0.9s of UT1, a measure of earth's rotation.

Due to historical reasons the length of a second was defined somewhat shorter than 1/86400 of a mean solar day at the time our current definition was established. Because of this the trend between UT1 and UTC is largely in one direction and all leap seconds, so far, have been positive. But leap seconds can be negative if earth's rotation speeds up enough.

As things are leapseconds are a barely mitigated disaster: They, like their distant cousin daylight savings time, cause widespread disruption in time sensitive electronic systems for very little benefit: Without leapseconds it would take thousands of years for UT1 and UTC to diverge by an hour-- and at that point, if we really cared, we could update timezones to move noon closer to astronomical noon.

Leapseconds even cause outages and system failures when they're not even happening due to false leapsecond events and the difficulty of validating leap-seconds (https://news.ycombinator.com/item?id=28046997). Though the offsets caused by leapseconds are small they're worse than DST because DST is a timezone effect while leapseconds make the UTC timebase our systems count on unreliable.

Recently earth's rotation has been speeding up, causing the UT1-UTC offset tend to stall and begin moving in the opposite direction. At some point this may result in the issuance of a negative leapsecond. Since ordinary positive leapseconds cause…

The article title should include (1997) as the year it was written.

Much better (updated much more recently with the latest developments) link is:

http://www.cl.cam.ac.uk/~mgk25/time/leap/

also

http://www.ucolick.org/~sla/leapsecs/

"In 1970 the CCIR (predecessor of the ITU-R) decided to disconnect clocks from the rotation of the earth, but they kept the calendar connected to the rotation of the earth. That decision was implemented starting in 1972, and since then the leap seconds have maintained the connection.

In 2015 the ITU-R will decide whether the calendar will also become disconnected from the rotation of the earth. If the ITU-R decides to abandon leap seconds in UTC then the calendar day will become regulated purely by cesium atoms, not by sunrise, noon, sunset, nor midnight. The ITU-R will choose between these two options."

More background:

http://www.ucolick.org/~sla/leapsecs/amsci.html

The possible solution:

For most uses knowing about leap seconds is unnecessary. Ignoring them is convenient and enough for the common computers: you as the programmer can then assume that every day has 86400 seconds, and the variations due to leap seconds are probably less than those that happen due to your computer not having the atomic clock built in (the time provided by your hardware is, unsurprisingly, much less stable than the one of the atomic clocks and you probably don't care).

The most recent popular article by Kuhn (2015) explains the problem most of the…

Mostly due to tidal friction from the moon, Earth’s rotation is slowing down in the long term. If we don’t adjust our clocks, the difference between the solar day and our clocks will slowly grow, quadratically. See this site for more details and nice graphs: https://www.ucolick.org/~sla/leapsecs/

In 1972 it was decided that the best way to compensate for this is to insert (and sometime remove) leap seconds, so that the difference between UTC and Earth’s rotation is kept below one second. A certain subset of astronomical and navigational/satellite applications rely on that condition being true. If this is changed, some decades-old systems, some of which may be critical infrastructure, may have to be substantially modified to account for leap seconds in some other way. The mention of GLONAS in the article is one such example.

In the international standard body responsible for UTC (ITU-R), there was up to now no sufficient majority in favor of abolishing leap seconds, due to those concerns. (Never change a running system, so to speak.) By now it has become apparent that the benefits of dropping leap seconds should vastly outweigh the potential drawbacks, at least for the next few decades. But it took some time for that realization, and probably also some older participants whose minds couldn’t be changed to die off.

Well, you can't, because GMT is not well-defined. It's been through numerous revisions, so that if you want to specify a time in GMT, you also need to state which revision of GMT you are using. GMT is now an obsolete timescale.

GMT has generally been some form of "Mean Solar Time at Greenwich". If you're specifying a time well in the future, then for the same reason as UTC in the future is ill-defined, so is Mean Solar Time at Greenwich. If the speed of the Earth's rotation has changed (it will have) then there's no way of knowing the numer of seconds between now and "January 1, 2030, midnight GMT".

The term is nowadays used to refer to UTC, but in a handwavy way. The BBC refers to all its time announcements as being something "GMT", which they enunciate in a smug, jingoistic tone of voice. It sickens me (and I'm a brit).

Here's an excellent article detailing the relationships between different timescales, paying particular attention to the "sordid history of GMT".

https://www.ucolick.org/~sla/leapsecs/timescales.html

It's frustrating that programmers want to redefine civil time just because it is "hard". This article glosses over the real world problems that detaching from UTC will cause.

This article details some of the problems: https://www.ucolick.org/~sla/leapsecs/dutc.html

(You may want to scroll down to "Implementing the plan outlined at Torino".)

If we end leap seconds, it doesn't take long - only until 2028 - until "midnight" is sufficiently far from "the middle of the night" that you will have to consider the legal issues caused by events that happen just before or after 0000 hours.

By 2055, the "minute" displayed on a clock may be incorrect, which again may cause issues with legal timestamps.

And by 2083, sundials are measurably wrong.

All because programmers wanted to save some lines of code.

> This article details some of the problems: https://www.ucolick.org/~sla/leapsecs/dutc.html

That article is ridiculous.

* "Most telescope pointing systems fail" (by 2027) (with 5s deviation from earth rotation). Pointing systems cannot blindly rely on UTC anyway, since (a) even with leap seconds UTC is up to 1 second off earth's rotation, and (b) pointing a telescope depends on where the telescope is on earth, so some offset must be added to UTC by some human.

* Hypothesized legal issues... give me a break.

It would be much less trouble for humanity to deal with this once every 100 years or so.