Context: BIPM is responsible for the UTC time standard, and in this document they decide to stop adding (or removing) leap seconds, starting on 20th of May 2027 and lasting for the foreseeable future (until one leap hour is needed). Together with the decision to not add a leap second in December, the 27 leap seconds that have been added so far should be the only ones.
The page lists several good reasons for this, including:
- It's a common source of bugs.
- IoT, embedded systems, and anything that cannot receive time updates have trouble with leap seconds.
- Negative leap seconds have never occurred before, but might occur in the future, and almost no software has tested this case.
I'd also add:
- Unix timestamps are actually defined as "seconds since epoch minus however many leap seconds have happened". It's a hack to make the keep code that assumes 86400 seconds in a day from breaking. It means that during a leap second the Unix timestamp goes back and repeats a previous value, making them ambiguous and non-monotonic.
- Leap seconds can make it impossible to predict how many seconds are between two UTC dates or Unix timestamps, for example the countdown to the year 2038 bug.
@dan: can we rename this to "BIPM decides to stop adding leap seconds to UTC" or something similar? This title is really downplaying the situation, I think readers over here care a lot about this.
> @dan: can we rename this to "BIPM decides to stop adding leap seconds to UTC" or something similar? This title is really downplaying the situation, I think readers over here care a lot about this.
@-tags like this don't do anything, you're better off sending an email. I think hn@ycombinator.com is the address.
> - Leap seconds make predicting the clock time of timestamps in the future impossible.
I don’t see that reason listed on the page, and future wall-clock times remain unpredictable due to changes in time zone rules.
What will become predictable is the relationship between posix time and elapsed time (in the sense of TAI), at least within the next few hundred years.
Goodbye sundial welcome cesium clock. Astrology app devs: remember to carry the drift in Temporal for the Ascendant, specially around 2267 you might get your love and money life predictions messed up.
Am I wrong in interpreting this as just pushing the problem (divergence between International Atomic Time and the rotational speed of the earth) 100 years in the future?
This essentially means being less anal about ensuring the earth has the exact same clock time at the exact same earth-sun-relative rotational position. Turns out the earth spins up and slows down semi-randomly with a magnitude big enough to require positive or negative leap seconds every few years, and it's just not worth the effort. Leap minutes might only be needed around every 100 years, but that would still be annoying, so they dropped all the way to leap hours, probably not needed for thousands of years. As long as the sun rises in the morning and sets in the afternoon, that saves on a lot of frequent minor adjustments. Timezones are already an hour wide anyways, and the sun isn't in the same spot when you're on the western vs eastern edges.
Sure, you could also run a relativistic simulation of the solar system, galaxy, and cosmos to establish a more monotonic clock and calendar independent of imperfect orbital parameters, but that's a bit much for discerning whether or not it's lunchtime.
Several hundred years at least (see my sibling comment). And in all likelihood this will be handled by shifting the time zones by an hour, or possibly by omitting one DST adjustment in spring.
In the very far future, leap seconds would become inadequate anyway, as you’d have to insert them every month, then every week, then every day, due to the deceleration of Earth’s rotation.
Context: BIPM is responsible for the UTC time standard, and in this document they decide to stop adding (or removing) leap seconds, starting on 20th of May 2027 and lasting for the foreseeable future (until one leap hour is needed). Together with the decision to not add a leap second in December, the 27 leap seconds that have been added so far should be the only ones.
The page lists several good reasons for this, including:
- It's a common source of bugs.
- IoT, embedded systems, and anything that cannot receive time updates have trouble with leap seconds.
- Negative leap seconds have never occurred before, but might occur in the future, and almost no software has tested this case.
I'd also add:
- Unix timestamps are actually defined as "seconds since epoch minus however many leap seconds have happened". It's a hack to make the keep code that assumes 86400 seconds in a day from breaking. It means that during a leap second the Unix timestamp goes back and repeats a previous value, making them ambiguous and non-monotonic.
- Leap seconds can make it impossible to predict how many seconds are between two UTC dates or Unix timestamps, for example the countdown to the year 2038 bug.
@dan: can we rename this to "BIPM decides to stop adding leap seconds to UTC" or something similar? This title is really downplaying the situation, I think readers over here care a lot about this.
> @dan: can we rename this to "BIPM decides to stop adding leap seconds to UTC" or something similar? This title is really downplaying the situation, I think readers over here care a lot about this.
@-tags like this don't do anything, you're better off sending an email. I think hn@ycombinator.com is the address.
> - Leap seconds make predicting the clock time of timestamps in the future impossible.
I don’t see that reason listed on the page, and future wall-clock times remain unpredictable due to changes in time zone rules.
What will become predictable is the relationship between posix time and elapsed time (in the sense of TAI), at least within the next few hundred years.
Good, point, I've reworded that bit.
A practical solution. As long as we can keep 12:00 near high noon and 00:00 near "high midnight(?)", that should be good enough.
Goodbye sundial welcome cesium clock. Astrology app devs: remember to carry the drift in Temporal for the Ascendant, specially around 2267 you might get your love and money life predictions messed up.
Short: no more leap seconds
TL;DR: No more leap seconds. The replacement will not be leap minutes but leap hours.
…the next which is expected in roughly a 1000 years: https://www.ucolick.org/~sla/leapsecs/futuredelt.svg
Am I wrong in interpreting this as just pushing the problem (divergence between International Atomic Time and the rotational speed of the earth) 100 years in the future?
This essentially means being less anal about ensuring the earth has the exact same clock time at the exact same earth-sun-relative rotational position. Turns out the earth spins up and slows down semi-randomly with a magnitude big enough to require positive or negative leap seconds every few years, and it's just not worth the effort. Leap minutes might only be needed around every 100 years, but that would still be annoying, so they dropped all the way to leap hours, probably not needed for thousands of years. As long as the sun rises in the morning and sets in the afternoon, that saves on a lot of frequent minor adjustments. Timezones are already an hour wide anyways, and the sun isn't in the same spot when you're on the western vs eastern edges.
Sure, you could also run a relativistic simulation of the solar system, galaxy, and cosmos to establish a more monotonic clock and calendar independent of imperfect orbital parameters, but that's a bit much for discerning whether or not it's lunchtime.
Several hundred years at least (see my sibling comment). And in all likelihood this will be handled by shifting the time zones by an hour, or possibly by omitting one DST adjustment in spring.
In the very far future, leap seconds would become inadequate anyway, as you’d have to insert them every month, then every week, then every day, due to the deceleration of Earth’s rotation.