Hacker News Reader

Reading all these reasons sounds like defeat to me. It is sad that in 2026 we cannot even pull off a simple thing like adding or removing a second rarely and long announced to one of our time definitions.

And it's not that we wouldn't have a time without leap seconds. Instead of changing the time definition it would make much more sense to switch to TAI for me. Now we will have tons of UTC code hanging around with support for leap seconds that will never be used and if you want to remove it you will have to distinguish between old and new UTC. Not a fan.

IMO it's not a simple thing, even at a surface level.

"A minute has 60 seconds" is simple.

"A minute has 59, 60, or 61 seconds. Consult CGPM publications or your national timekeeping authority to find out." is not simple at all.

For thousands of years, we used time synchronized to the sun, with flexible intervals. That’s the natural thing for a lot of things, and that is what UTC is for.

Now, if you don’t care about the sun but about fixed intervals, you can always use TAI.

Standards are there to serve people, and we should have the choice to use the standard that fits our needs best. Changing the meaning of a standard retroactively, with no good reason and when a good alternative is available, is nothing short of irresponsible.

UTC is still fixed to the sun. Without leap seconds, it will be hundreds of years before the divergence between UTC and the sun is perceptible in daily life. Even then, I can't think of anything where that would matter.

I think there is a good alternative available, UT1. UTC was always divergent from UT1 anyway, so this change shouldn't affect anyone who actually needs precise solar timekeeping.

More importantly, there are many good reasons to drop leap seconds, such as the massive increase in complexity they impose on all time-related code.

Standards should serve people, which is why leap seconds should never have existed. Imagine: "Sure some airliners crashed, and half the internet went offline for a couple days, but if you drive to the right longitude line, the sun will be exactly overhead at 12:00:00, and here in town it's overhead at 12:23:48. That's worth anything. I'd hate to live in a world where it was overhead at 12:23:49, or that'd be over my great-great-great grandchildren at 12:23:47."

The promise of UTC is bounded deviation from solar time while keeping the intervals of ISO seconds. I think this is a valuable trade-off that should continue to exist.

> I think this is a valuable trade-off that should continue to exist.

And it has, the bound on the deviation was increased slightly to 3600 seconds

Nope, the whole point of this is to remove the coupling for UTC. You can either have monotonic time (or at least per-observer monotonic time), or you can follow earth's rotation. Choosing monotonic time is perfectly fine (and feel free to pick your epoch and time unit), but like we have timezones such that 12:00 means something (mostly), having the human conception of what time means does imply that we do kinda need to look at what's happening outside.

I'd prefer if dUT1 was restored to ±.9s after NTP rollover in 2036, Y2K38, and GPS week rollover in 2038. This way we now know precisely what the UTC times will be for those events and dUT1 probably will be <10s at that point. Software will need to deal with times like 23:59:63 properly by then (too much still can't handle 23:59:60 leap seconds yet). Maybe we could have dUT1 < ±9.9s going forward.

The problems with letting dUT1 > 1800 and above is that well before that it starts mattering for almost everything and then you have to consult the solution (here's just 2025's):

  https://crf.usno.navy.mil/quarterly-vlbi-solution

That's generated by the US Navy for all intents and is way more data than used now for leap seconds which are fine enough of a granularity for most things. Future timestamps in UT1 will get difficult to handle as well. Previously software could assume it knew to the closest second which was often good enough.

I'm not sure if I completely follow you, but I'd like to ask: Why is it a problem if there's a divergence between UT1 and UTC? Besides astronomers, who cares if the sun is directly overhead a few minutes later than it "should" be?

Everyone who paid for expensive equipment that gets UT1 time to a tenth of a second in a year or two.

https://www.nist.gov/pml/time-and-frequency-division/time-di...

For thousands of years, we used time synchronized to the sun to some approximation that was off by minutes, not microseconds, and nobody cared if the current time relative to the sun was off by a second because they had no way of actually determining that. And then some jerk came along and invented computers and precision timekeeping and suddenly things depended on things like time not appearing to move backwards by as much as a second. :)

We have GMT for standardised solar time. I assume there were good reasons for moving to UTC? Either is fine for many purposes.

So, the thing you probably want for "standardized solar time" is named UT1, there are a bunch of complicated technical details here, which do not matter, but ultimately UT0 and UT2 are not relevant to normal people, UT1 is a hypothetical solar time, estimated by observatories, and UTC is the world's civil time, now fixed to TAI plus 37 seconds.

GMT (Grenwich Mean Time) is a legacy from when Britain (and thus Grenwich, an observatory in London, England) was more important. These days GMT, even in British legislation, just means UTC. When we say "In the winter we use GMT not BST" we're not switching to or from some archaic time system, GMT is just defined as UTC+0 and BST is defined as UTC+1 the same way summer time zones work in several others places which have them.

GP wanted solar time, so that would be old style GMT, which would be now UT1, right?

UT1 is what you'd actually use if you specifically want solar time today, yes.

I'm just highlighting that in most places when it says "GMT" it does not mean solar time, just like how "New Street Station" in Birmingham is not in fact a New Station, or on a New Street, it's a station which was close enough to the road in Birmingham named "New Street" that it's forever associated.

When actual Grenwich Mean Time was "still a thing" astronomers would use it for solar time because we had no better approximations. Today the IERS looks at very distant objects in the sky. We know that in some sense (relative to us) these are not moving because they're incredibly far away, and so we can use them to measure rotation. And then we adjust for where the Sun is from that data.

More importantly, in the second case the definition is not static so implementations will inevitably disagree which makes things an even bigger mess.

As I understand it, almost nobody was actually using UTC anyway.

Almost every programming language and database I've ever used assumes 86400-second days, ignoring leap seconds. And one of the popular ways of applying leap seconds was a 'smear' [1] running every clock slightly fast for about 24 hours, rather than having a 61-second minute.

So instead of UTC we actually all use a slightly elastic timescale with the name of UTC, most of the time aligned with UTC, but with the linearity of TAI, and the desirable property that if I'm going to a concert at 19:00 in a year's time and a leapsecond is announced and implemented in the interim, the concert doesn't change to 18:59:59.

[1] https://developers.google.com/time/smear

I have yet to see a single clock able to show 23:59:60. Not just computers, any clock at all

Every system seems to either 1) jump back/forward, 2) smear, 3) ignore it because a drift of more than one second is already accepted in that system

I used to have an oven whose clock would display 23:60 before jumping to 00:01!

Well that's just pure insanity. I have to know this now. I didn't need this :D

I believe one of the alarm clocks I have owned around the turn of the century could display 23:59:60 and understood leap seconds.

However that's a radio alarm clock which also knows the exact date-time, including year - one of the best presents I have ever received from friends who saw it and realised oh, that is exactly what tialaramex needs. In the smartphone era I do not need one.

It's very rare. I wrote my own clock application to properly see the leap second back in 2015. Here is a recording: https://fedorapeople.org/~mlichvar/leap2015/clock_step.gif

A leap smear for a leap-second insertion needs to run the clock slower, not faster.

I also see this as a defeat. BIPM's Bulletin C announcing the leap second or lack thereof, is almost always very close to full six months before the event. Even this is almost enough time to both develop and test an implementation, not just test it, plus there are usually years of no action between the events.

> Instead of changing the time definition it would make much more sense to switch to TAI for me.

Should UTC permanently stop diverging from TAI, it is more likely that the opposite would happen - TAI would be subsumed by UTC, because there would be no need to maintain two timescales.

Systems which prefer not to deal with discontinuities already use TAI. Many packet capture / timestamping systems natively operate in TAI, and UTC conversion is/can be done in "post-processing". Many / most time servers also do internally, and for example the native time scale for IEEE 1588 / Precision Time Protocol is TAI, and UTC->TAI offset and leap events are announced separately. NTP though, while using its own epoch, is still UTC aligned and while it indicates the LS events, it operates on discontinuous timestamps.

TL;DR: Time sync hard; must make easy.

> Reading all these reasons sounds like defeat to me.

Agreed.

I never really understood the big issue with these. Systems need to be flexible enough to compensate for clock drift between devices already. On cheap devices like IOT devices (called out in this memo for their lack of capabilities) clocks diverge _all the time_ because cheap timing crystals aren’t great.

Even on expensive desktop PCs, audio and video hardware clocks diverge enough that compensation is required just to watch a YouTube video with the audio synchronized with video all the way to the end, and that’s without Bluetooth devices and the like inserting even more clocks into the system.

If our systems can’t cope with smearing a leap second in either direction every now and then, something is wrong.

Any prospect for a leap hour is toast by the time we need it. Over a thousand years of ossification will mean our only option is to not care about aligning clock time to the sun. So it's kinda a joke to even talk about leap hours. I'm shocked they're even mentioning such an idea, they should have declared it as a non-solution.

The resolution doesn't actually mention leap hours, just that the delta is allowed to grow up to one hour. What should happen then is to be decided by future generations.

A tzdata update. Boom, done.

Reminds me of the old "book the meeting on Feb 31" trick to avoid an unwanted meeting.

Heh, I save periodic events as intervals in the database. The upside is it handles weird things like this surprisingly robustly, the downside is that months are months past the start of the year and days are days past the start of the month, yes every thing is zero based. I like it, I feel like I am rebelling against a broken system, but have to make sure I do a conversion to one based months and days for everyone else. Time of day and years are fine, time is already zero based and nobody cares about seeing a year 0.

So the example given Feb-31 is stored as 1 month + 30 days past the start of the year and would trigger right on time march 2nd or 3rd, depending on leap year. In fact I started doing it to handle birthdays on leap day, there is not always a February 29, but there is always a day 29 days after the start of February.

FWIW, Rare Disease Day is celebrated on Feb. 29.

Treating birthdays on Feb 29 as if they happened on March 1 in non-leap years is wrong in places like California and New York -- at least probably most of the time, because while I already knew that, I didn't appreciate how deep the rabbit hole actually goes.

* https://leginfo.legislature.ca.gov/faces/codes_displaySectio...

* https://www.nysenate.gov/legislation/laws/GCN/58

Surely by then we'll have the technology to simply adjust the Earth's rotation so that it conforms to our standards.

A century later we'll finally be able to fix Earth's orbit to make a nice round 360 days per year, 12 months of 30 days, nice and clean, no more complexity or confusion... ah, that'll be the day.

> our only option is to not care about aligning clock time to the sun

No, an easy option is to simply shift every timezone by an hour and keep UTC intact. A ton of places already do that twice a year for daylight savings.

I never understood why we mess with UTC so much when we already have another widely used mechanism to keep the sun and clocks aligned.

Sure, but political timezones shifted by more than 12 hours 65,000 years in the future seems like the sort of thing that would really screw up our existing code. (I wonder what happens if you put such an entry in tzdata right now? Maybe we should put Null Island at +37:00 or something crazy like +1000:00 to start hardening now)

And maybe we should stop touching political timezones by then anyways.

There is a bit of a fine line between caring about the future and not screwing them over, versus just being so arrogant as to think we know now the right thing to do for them.

But given the amount of time it is going to take to accumulate so much as another leap minute's worth of leap time, let alone an hour, I'm pretty confident we're in the "arrogant" branch if we start declaring what they need.

P(nobody cares about UTC anymore anyhow | someone had to solve the problem of incorporating non-terrestrial time which is way harder than leap seconds) would seem to me to approach 100%. You can decide which branch you want to take, but P(things just keep on keeping on without much change from today for the next several thousand years) seems not large enough to start trying to make lots of plans for.

Time zones change all the time, often on amazingly short notice.

Random local government people declare it is to be, and ... as an industry we largely figure it out.

The more responsible governments give amble notice and as an industry we are very very good at that (you not realizing it, is an example).

And good riddance to leap seconds! It was too hard for us to figure out, and they didn't do anything useful for anyone.

Right, we have the capability to update timezone definitions in a standardized automatable way right now, but 14 hours is the furthest timezone offset a political timezone has ever had. The distant future will require the offset to drift by multiple earth rotations, which puts a wrench in the flexibility of existing systems even if the tzdata database compiles properly. For example, this would break Java's ZonedDateTime as it only supports offsets up to 18 hours.

Just define new epoch at the turn of a century. Like a "UTD" or "UT2" that begins like 2200/01/01 00:00 that is actually UTC 2199/12/31 11:43:21 or something. Then hardcode the magic TAI number in the headers along the gravity constant and such. Solves the time_t problem too if done every centuries; 2^32 seconds = 136.102208 years. The biggest concern will be that kids at that time will start asking why there was never been UTB and UTA, which our oldest grandkids wouldn't actually know why.

In less than half a century, we've created 3 different time standards (TAI, GPS, and now UTC) that tick identically and differ only by arbitrary constant offsets (+37, +18 and +0 seconds). If we haven't come up with an elegant solution by then it's likely 65000 years from now most computing power will be spent running time-conversion libraries.

You'd just shift timezones-- which happens from time to time for political reasons and is well supported.

... of course you're talking about events that would be approximately 4000 years from now!

they should have mentioned leap day instead. or leap month! if we're going for arbitrary long time period predictions, why stop in some 70k years only?

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.

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. But thanks for bringing this to our general attention! It's great news.

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

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

“Stuff FreeBSD does” falls pretty neatly into the “almost no software” category, to be fair.

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

Currently a 'time' is ambiguous if it doesn't come with a timezone. And if it does come with a timezone, then there is no issue with that future shift. You wouldn't redefine EST you'd create an EST2 that was shifted (and which people would colloquially call 'Eastern' after long enough).

So the exact duration between any two times would be easily computed, so long as those times were precise enough to include their timezone-- which they have to be already.

tzdata routinely issues historical corrections in newer versions.

So while the political time zones don't change retroactively, the technical rules used in computers can.

> if it does come with a timezone, then there is no issue with that future shift.

There is no issue that didn’t already exist, but it remains true that future wall-clock times cannot be predicted with certainty, because tzdata may change between now and the future time.

When someone sets an alarm for 12:00 in five years in the current time zone, how do you store that? It can make a difference whether you store it as a Unix timestamp or as broken-down time plus time zone.

You store the future alarm as a wall clock time and date plus location, without making any assumptions about what the civil time offset is going to be on that particular date in that location. When the time comes, whatever system has to read your record and raise the alarm will know what the local time is.

> IoT and anything that cannot receive time updates have trouble with leap seconds.

Could you make an example application where it could be an issue? I imagine it would have to be an appliance that needs high precision time, is not connected to the internet, and hence it has an internal clock that is accurate over long times.

I concur that this is probably a good thing, but UTC without leap seconds already exists. That is TAI and some applications that care about long term persistent and self-consistent telemetry use that.

I agree, except that TAI is off from UTC by 37 seconds.

That's a pretty big smear if you want to convert an existing clock from one to the other.

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

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.

Dan has confirmed in the past that he doesn’t, and that one should send an email. (Also, usually people use @dang and not @dan.)

Oops^2. I sent the email, thanks.

But does that mean that UTC time will diverge from common time zones by more than a fixed number of hours (and minutes for a few esoteric time zones)?

The time zones are defined as UTC + some offset, so no. What UTC will diverge from is solar time (UT1 in the article), so that solar noon might not happen at 12:00 anymore.

But because the sun's trajectory changes throughout the year, and we live in very coarse timezones already, it was always a bit useless tracking this with seconds precision.

> so that solar noon might not happen at 12:00 anymore

The solar noon never happens at 12:00 anywhere anymore. We've left that era about 200 years ago when we synched clocks with the capital city for the benefit of train schedules.

P.S. Well, technically the solar noon happens at 12:00 in New York on January 2nd, Chicago on Jan 14, Denver on Dec 25th, Los Angeles on Jan 9, etc. (on other dates, it's off.) In Santiago de Compostela — where they want to be on the same clock as Warsaw — solar noon happens as "early" as 13:18 and as late as 14:40.

are you saying that we may have a situation where 10:00:10 UTC might be 11:00:11 BST ?

If so I'm failing to see how this is less likely to cause bugs

No, never. BST is defined as UTC + 1 hour. The leap seconds were making both UTC and BST jump around, and now neither will jump around anymore.

Is my understanding correct that they maintain a time called UT1, which is basically UTC if it continued to have leap seconds?

In simple terms UT1 is the time if we let seconds be defined by the earth's rotation. UTC was kept in sync with this rotation by introducing leap seconds, while still adhering to the stable ticking of TAI (cesium clocks).

From now on UTC will in practice be TAI but with a constant offset (=all previous leap seconds).

> almost no software has tested this case.

This part I simply fail to understand. In the age of CI and formalised approach to testing? What about, simply, "good engineering practices"? What, we look at a (defined, described, standardised) corner case and go "naaah, how likely is that...", and just let it slide? What, if we have a 64-bit counter somewhere, do we go "how likely is that to roll over..."? I f# hope we don't.

In any case, I don't accept the "hasn't been tested" argument. Those mechanisms have been in place for decades now, so what if we had no occurrence. I think this is helpful FUD and buzz generated to accelerate moving away from a slightly cumbersome maintenance event, and I get it, but the "not tested" to me, is (or should be!) an insult to software and hardware engineers out there.

As someone involved in time sync and always on alert during leap seconds (leap second party anyone?), I have mixed feelings here. On the one hand this is less work, but on the other, it is a triumph of reducing complexity - or laziness, dare I say - over "correctness".