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.
>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.
GLONAS and other GPS like systems already have to deal with the temporal effects of special AND general relativity in their time keeping. Pushing leap seconds off on to the already special case system seems like a fair trade for making every other programmer and sysadmins life easier. let the extreme corner cases deal with their problems not everyone else.
Few systems actually should need to depend on the clock tick matching actual elapsed seconds, and those who do depend on accurate elapsed time usually only do so short-term (while the program is executing) and don’t need to correlate that time with calendar dates and time-of-day. Most applications could very well live with an intermittently slowed-down time-of-day clock upon leap-second insertion, or a fast-forward upon leap-second removal, and use a different API when they’re interested in accurate elapsed time. But APIs have conflated those concerns, increasing the likelihood for something to grow when e.g. unix time diverges from accurate elapsed time.
I like to think that applications should be written under the assumption that the computer could be used by time-travellers, with the clock reflecting the respective changes to “local” time. That is, you would have calendar dates and wall-clock times reflecting the time travel, plus an elapsed-time clock reflecting the CPU’s subjective time. Then design your systems around that. As a consequence, they should also be immune to leap seconds and DST switches. But I guess that’s too much to ask. ;)
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.