3 ms·

I've heard of the endless disruption that leap seconds cause for years and only now have I thought to ask the question: what was so important that the entire wo

by c3534l 4y ago

I've heard of the endless disruption that leap seconds cause for years and only now have I thought to ask the question: what was so important that the entire world needed to add or subtract individual seconds from the calendar? Seems like you'd need a pretty big justification for something like that, but I only here the horror stories, not what the leap second was supposed to actually solve.

layer8 4y ago
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/ 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.
- smegger001 4y ago
  >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.
- c3534l 4y ago
  Fair enough. I guess in those days, there weren't as many systems that depended on the assumption of time lurching forward one second at a time.
  - layer8 4y ago
    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. ;)
    - layer8 4y ago
      s/grow/go wrong/

by c3534l 4y ago

layer8 4y ago

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/ 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.

smegger001 4y ago
>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.
c3534l 4y ago
Fair enough. I guess in those days, there weren't as many systems that depended on the assumption of time lurching forward one second at a time.
- layer8 4y ago
  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. ;)
  - layer8 4y ago
    s/grow/go wrong/