Yet another Hacker News

The technical actions needed to ensure the continuity of UTC

40 points gliffie 1 hour ago 20 comments

smartmic 1 hour ago | parent

Short: no more leap seconds

jcranmer 1 hour ago | parent

TL;DR: No more leap seconds. The replacement will not be leap minutes but leap hours.

krunck 59 minutes ago | parent

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?

layer8 57 minutes ago | parent

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.

hnuser123456 50 minutes ago | parent

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.

wahern 30 minutes ago | parent

> Sure, you could also run a relativistic simulation of the solar system

Barycentric Coordinate Time: https://en.wikipedia.org/wiki/Barycentric_Coordinate_Time

layer8 59 minutes ago | parent

…the next which is expected in roughly a 1000 years: https://www.ucolick.org/~sla/leapsecs/futuredelt.svg

throw0101c 20 minutes ago | parent

> …the next which is expected in roughly a 1000 years: https://www.ucolick.org/~sla/leapsecs/futuredelt.svg

Which doesn't seem like that is soon, but time/calendar issues can creep up and then it's a big hullabaloo:

* https://en.wikipedia.org/wiki/Gregorian_calendar

throw0101c 25 minutes ago | parent

> The replacement will not be leap minutes but leap hours.

People have a hard time with leap years, which happen regularly every four years, so I'm curious to know how well a "one-off" event at a basically random time in the future will work.

frangonf 1 hour ago | parent

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.

basilikum 5 minutes ago | parent

They don't care that the dates of the astrological signs have shifted and assign zodiac signs to you that have nothing to do with the constellation of stars at your birth, so I have a feeling they won't care about that either.

hnuser123456 55 minutes ago | parent

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.

BoppreH 50 minutes ago | parent

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 second unpredictability can make it impossible to calculate 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.

layer8 46 minutes ago | parent

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

BoppreH 39 minutes ago | parent

Good, point, I've reworded that bit.

likpok 41 minutes ago | parent

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

BoppreH 38 minutes ago | parent

I'm well aware that HN doesn't have @ tags, but I would be surprised if dan doesn't have something listening for this specific string. And not a big enough deal to warrant an email in my opinion, but you're free to send one.

throw0101c 32 minutes ago | parent

> - Negative leap seconds have never occurred before, but might occur in the future, and almost no software has tested this case.

FreeBSD tests stuff like this for the code that they take care of:

* https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove...

Third-party stuff (like from Ports) is another question.

gliffie 25 minutes ago | parent

Thank you for providing context for other readers. I was unsure what do to with the title, as my experience is that editorialized titles are always eventually changed to the original title. The "actual" title here is "Resolution 5 (2026)", but I decided to go with the much more specific subheading "On the technical actions needed to ensure the continuity of UTC". Curiously, "On" was removed on submission.

BoppreH 17 minutes ago | parent

My first interpretation of the title was that UTC was in danger of something that needed fixing. It didn't occur to me that "continuity" meant in the mathematical sense.

On a side note, I really like how the site laid the reasoning. I'll be copying it to my technical writing.