No leap second 2026-06-30, per below. See attached patch. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center Date: Tue, 6 Jan 2026 at 06:50…
No leap second 2026-06-30, per below. See attached patch. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc@obspm.fr> Date: Tue, 6 Jan 2026 at 06:50 Subject: Bulletin C number 71 To: <bulc.iers@obspm.fr> INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE DE L'IERS OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : +33 1 40 51 23 35 e-mail : services.iers@obspm.fr http://hpiers.obspm.fr/eop-pc Paris, 06 January 2026 Bulletin C 71 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO leap second will be introduced at the end of June 2026. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is : from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Christian BIZOUARD Director Earth Orientation Center of IERS Observatoire de Paris, France
Page 2
No leap second 2026-06-30, per below. See attached patch.
e-mail : services.iers@obspm.fr
http://hpiers.obspm.fr/eop-pc Paris, 06 January 2026 Bulletin C 71 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO leap second will be introduced at the end of June 2026. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is : from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Christian BIZOUARD Director Earth Orientation Center of IERS Observatoire de Paris, France
Read the original article
Comments
Responding to a deleted comment:
> ... the "invisible infrastructure" of the web; balancing historical accuracy with the technical need to minimize zone fragmentation is a much more complex trade-off than it appears on the surface ...
The complexity goes up tremendously if some condition is rarely encountered: eg leap second. This means it gets pushed to a "corner case" and tested more lightly and more rarely.
At $work around 2014 we had three different hardware GPS types which we used for precision timekeeping; some chips, daughterboards, and firmware. One day a leap second arrived -- it gets broadcast to aGPS hardware a day ahead of time -- and all three implementations handled it differently. One handled it, one did something else like ignore it, and I think one even bricked itself. That situation was less than bueno.
By throw0101d 2026-03-0916:0814 reply > The complexity goes up tremendously if some condition is rarely encountered: eg leap second. This means it gets pushed to a "corner case" and tested more lightly and more rarely.
There is some talk of eliminating the leap second, which would over time have the Earth and sun diverge with regards to noon and such. One 'answer' to this concern is to have a 'leap hour' or something in the future (some future generation's problem, not ours): but given that people can't even get February 29th correct now, and it happens regularly, I don't see how a one-off event would be made to work. It'd be a huge coördination problem.
Just look at the introduction of the Gregorian calendar: it was slightly off since the time of Julius Caesar, but that minor error added up over time, to the point that to get the equinoxes/solstices back to where they 'should' be 10 days had to be removed with the Gregorian calendar. And because of politics (or a religious flavour) it took a long while for everyone to get on the same page.
> One 'answer' to this concern is to have a 'leap hour' or something in the future
We've had 27 leapseconds in the last 54 years [1] - an average of 0.5 seconds per year.
At that rate, solar time will drift by 60 seconds over the course of 120 years. Drifting by 10 minutes will take 1200 years.
The leap hour will be in 7200 years, around year 9226.
By throwup238 2026-03-0921:293 reply > The leap hour will be in 7200 years, around year 9226.
7200 years ago the Neolithic revolution was still in full swing and many of the most famous megaliths like Stonehenge hadn’t even been built yet. The first real state, the Sumerian civilization, hadn’t formed yet in Mesopotamia.
Personally, I’m very comfortable making this someone else’s problems 7200 years from now. If they’re still having basic coordination issues then it’s their own damn problem.
By layer8 2026-03-100:44 You're missing that the frequency of leap seconds is accelerating over time, because Earth's rotation is slowing down. The leap hour will therefore happen earlier: https://www.ucolick.org/~sla/leapsecs/future2100.svg
Yeah. There’s also the issue that the earth’s rotation is slowing down, so over the long term leap seconds would become more and more frequent. There’s a point when the earth is slow enough that leap seconds need to happen nearly every month, and by that point they are no longer a workable solution to the problem. That is expected to take a few thousand years, comparable to the point where a leap hour would be needed if there were no leap seconds.
By darkwater 2026-03-107:21 > The leap hour will be in 7200 years, around year 9226
You mean 09226, I believe. [1]
[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
Leap seconds have so many problems beyond the time adjustment. It's a small/odd enough adjustment interval that there are wildly different approaches like leap smears. On top of being so small, it's rare enough (~every 2 years), depending on how a system is used, lack of proper handling might not be obviously apparent or lack of obvious problem in one implementation ignoring it may lead to lack of care in another implementation which would have a problem ignoring it.
Leap hour replaces all of that with what is more or less equivalent to a change in DST rules (except for more time zones at once). DST changes don't go perfect either by any means... but we do them regularly enough without the world crashing down that doing an additional shift change of an extra hour every 5000 years is almost certainly less hassle and breakage than the leap second approach breaking things every ~2 years.
By phicoh 2026-03-0917:51 It is way more easy to let UTC (without leap seconds) just drift away from the zero meridian and move countries to different time zones when convenient. We mess around with daylight savings time often enough that nobody will notice if we have change local time every couple of thousand years.
By throw0101d 2026-03-0917:541 reply DST changes are pre-scheduled. Throwing a random hour in/out at (say) June 30, 2029 may be something else. Unless the jump is treated as a TZ change in tzdata?
IMHO the correct way to handle leap seconds would have been at the same layer as timezones, i.e. a display-only thing. Timezone databases are regularly updated, you push out leap second updates there. In the worst case, people's clocks are off by one second but all the underlying timing logic doesn't crash.
you can use TAI (international atomic time, basically UTC without leap seconds) if you want to be serious about it
I'm a fan but it's rare for anyone else to agree!
By Polizeiposaune 2026-03-0921:41 I fully expect in such a regime, people would be complaining about how the leap second insertion caused their recurring meeting to shift from 9am to 8:59:59
By tialaramex 2026-03-0916:202 reply The calendar adjustments are because the planet's constant orbital period isn't a whole number of days.
The leap seconds were an attempt to have wall clock time map to the planet's rotational angle consistently despite the problem that the planet's spin varies unpredictably.
Yes the "leap hour" is a legal fiction of course. In reality in the event anybody cares about this in the distant future they will make the kind of "drastic" changes you've probably experienced twice a year for your whole life and barely noticed... More likely because the drift is so incredibly slow they won't change anything.
By throw0101c 2026-03-0917:20 So lunar tidal forces are slowing the rotation, but (recently?) Earth mantle/core is causing a speed up, but climate change and melting ice is contributing to the slow down side:
* https://www.scientificamerican.com/article/leap-seconds-may-...
* https://scripps.ucsd.edu/news/global-warming-influencing-glo...
The general trend is slowing down. Apparently (?) once the day gets to be 24h+0.001sec (+1 millisecond), a leap second would occur about every 1000 days; then when it becomes 24h+0.002sec, a leap second would occur about every 500 days; when it reaches 24h+0.003sec, a leap second would occur about every year; etc.
By clickety_clack 2026-03-0922:431 reply In British Colombia they’re locking into daylight savings time, so I think it’s safe to say that people aren’t really bothered by solar accuracy.
By WorldMaker 2026-03-1018:25 I believe Vancouver is west enough in its time zone that Daylight time is going to be closer to Solar Noon in Vancouver (plus about 15 minutes? I haven't done the exact math) than Standard time was (minus about 45 minutes?). Vancouver is the economic heart of British Columbia and near enough to the centroid of BC's population that BC may have made the best choice they could for solar accuracy for the majority of the population.
By cesarb 2026-03-100:56 > One 'answer' to this concern is to have a 'leap hour' or something in the future (some future generation's problem, not ours)
A simpler solution: we already have an offset between local time and coordinated time, just change that offset. So, for instance, Brasília Time, which is currently UTC-03, would become UTC-02 or UTC-04, depending on which way the change went.
By philwelch 2026-03-0918:07 > There is some talk of eliminating the leap second, which would over time have the Earth and sun diverge with regards to noon and such
“Over time” really glosses over how much time it would take. In 500 years there might be half as much divergence between solar noon and 12:00pm as we intentionally inflict on ourselves with DST, or that France and Spain inflicted on themselves in the 1940’s so they could share a time zone with Germany. By the time anyone will even notice we will probably change time systems for other reasons anyway. It’s not even remotely comparable to the Julian/Gregorian issue, which dealt with leap days. Each day has 86400 seconds.
By TurdF3rguson 2026-03-0922:471 reply >There is some talk of eliminating the leap second
The concern, of course, is that some universes eliminating them while others don't can puts us out of sync. This creates a wobble that could potentially throw us out of Hilbert space.
By nstents 2026-03-0922:54 [dead]
By thaumasiotes 2026-03-109:371 reply > to the point that to get the equinoxes/solstices back to where they 'should' be 10 days had to be removed with the Gregorian calendar
Note that the equinoxes and solstices are officially supposed to be on the 25th. By the time of Julius Caesar, that had diverged, but the divergence in reality made no impact on the date of the official solstice. The Gregorian calendar could easily have put the solstices back on the 25th, but chose not to.
By the time of Julius Caesar, the solstices were on the 25th, which is the reason why Christmas is celebrated on that day.
The Gregorian calendar has not restored the time of Julius Caesar, but the time of the First Council of Nicaea (325 AD), when the rule about how to compute the date of the Easter was established.
From the time of Julius Caesar to 325 AD, more than 3 days of drift had accumulated, so the Gregorian calendar would have required 13 or 14 days of correction.
When many countries transitioned to the Gregorian calendar much later, they had to add additional correction days to the initial 10-day difference, about 1 day per century.
By adrian_b 2026-03-109:33 Unfortunately, the Gregorian calendar has not restored the time of Julius Caesar, but the time of the First Council of Nicaea (325 AD), when the rule about how to compute the date of the Easter was established.
For the time of Julius Caesar, about 3 more days would have been needed, which would have made the Christmas coincident with the Winter Solstice, and which would have made much more sense.
By b112 2026-03-0918:21 If you think you're going to steal days off my life, you've got another thing coming buster!
By euroderf 2026-03-0918:34 > There is some talk of eliminating the leap second, which would over time have the Earth and sun diverge with regards to noon and such.
<rant> It won't happen on a human scale. So why oh why do we screw around with this moronic leap-second nonsense ? Oh dear, in the year 4000 noon will arrive three minutes earlier compared to now. So? </rant>
Just here to reinforce your point.
The last leap-second I encountered (also the 2014 one) crashed my MySQL databases.
you wouldn't assume that it depends on time like that, because honestly why would it? "surely it's fine, NTP corrects drift of a second fairly frequently"- but a leap second is not a drift, it's something quite insane unless your primitives are solid. Nobody would test for this.
Yes I would assume that the NTP daemon would handle a leap second arrival with guarantees of (1) gradual application over a longer period and (2) never moving the clock backwards, only slowing it a little.
I wonder if all NTP implementations don't follow those guarantees?
Oh and another app that hates clock jumps used to be sshd; it would just bail out and drop all connections. We found that out while chasing ANOTHER bug in SunOS on a T4: they didn't have it mutexed right so it possible to read its RTC register while it was in the middle of getting updated so the client would read a garbage time. We chased NTP for a week before realizing it was the kernel.
By zombot 2026-03-106:24 Yea, can't be arsed to do it right, so let's just not do it.
By nineteen999 2026-03-1022:55 Very similar story at $mywork in 2016.
By Ozzie_osman 2026-03-107:003 reply The worst bug I ever dealt with in a 20 year career was a leap second bug (back in 2012). Servers all slowed down dramatically very suddenly, CPU saturated. No relevant code changes or changes in traffic. Turns out, they just got into that state due to a leap second. Some Livelock bug.
A restart fixed everything.
It wasn't just our site that went down. If I recall correctly, many other large sites (like Reddit, LinkedIn, etc) also had the same issue. Guess no one thought of the "did you try restarting it?"
By darkwater 2026-03-107:18 Yep, I was there too! HN thread from the time: https://news.ycombinator.com/item?id=4188412
By rwky 2026-03-1010:03 Me too! In my case postfix locked up and stopped sending mail there was a massive queue. I checked the logs and saw the same second twice and that's when I learned about leap seconds. Since then I have a reminder in my calendar every 6 months to check if ones been announced. Thankfully we've only had two.
By rausr 2026-03-107:11 I remember that well (because my manager at the time was asking me afterwards "why were you up at 2 in the morning restarting services?" and didn't believe my answer :( )
Computer systems (most importantly, UNIX) should've been using TAI [0] from the beginning. Human-readable time in turn should be computed from it using periodically updated time zones database which would include offset between TAI and UTC. By eliminating leap seconds we effectively re-invented TAI with a weird offset. While I am in favor of eliminating leap seconds as a hacky way to fix the current mess, it's sad to see that we added yet another quirk to the already complicated system of datetime keeping.
[0]: https://en.wikipedia.org/wiki/International_Atomic_Time
No, they should not.
We convert timestamps to and from date+times all the time. Having each day be exactly 86400 seconds simplifies this a lot, and practically every app benefits from that. Leap second smearing will ensure smooth and continious time.
Taking leap seconds into account is only needed in a very, very few contexts - maybe astronomy, or certain kinds of high-speed physics? Those rare users should be able to figure stuff out.
Go with UTC, don't optimize for rare usecases at the expense of everyone else.
Your message contradicts itself. Firstly it says leap seconds should not be used (aka TAI). But at the last sentence it says "go with UTC" (which has leap seconds).
>Having each day be exactly 86400 seconds simplifies this a lot, and practically every app benefits from that.
Making an assumption that a day 86400 seconds breaks at least twice a year in many parts of the world, and that's before we introduce leap seconds or possibility of your code running on hardware that itself travels across timezones.
By fuoqi 2026-03-104:51 You clearly do not know how much havoc and complexity leap seconds introduce into various systems. This is why leap seconds are likely to be phased-out [0]. It's effectively an admission that use of leap seconds in the "base" time was a mistake.
>We convert timestamps to and from date+times all the time.
If you do not account for time zones during this conversion, then you are not qualified to implement such conversions.
It's fine to use 86400 seconds for durations (e.g. "this computation will finish in 1d 8h 20m 34s"), but it's absolutely not fine to use it while dealing with datetimes.
[0]: https://en.wikipedia.org/wiki/Leap_second#Phase-out_and_futu...
By bloppe 2026-03-1016:32 I wish I could upvote this more. I've done so much timestamp work and this is the hill I was born to die on.
Huh, that's an interesting point. Not sure I agree though. I always was irritated by the complaint that leap seconds are complicated and must be eliminated, and I am convinced that eliminating them in UTC is the most idiotic decision ever made, and I sincerely hate the idiots who made it, but, indeed, the idea that UTC time is just a time-zone representation of linear TAI time on Earth does make a lot of sense. On the other hand, we still can convert between UTC and TAI, so treating TAI as primary only makes sense if it clearly would make things simpler. And it's very unclear if it would. It really seems like the "correct" abstraction, but the problem is that currently my main hack for avoiding time complexity is always using datetimes in UTC+0 internally, thus ignoring time zones until I need to display something for user. This way I know that 14:00 today + one month is still 14:00 in my "internal" time format, even if in the user TZ one is DST and the other one is not. And a hundred of other ugly things I am willing to ignore in practice. And in 99.999% of cases I don't even care how many days are in that month, let alone seconds.
Now, if I cannot really add a month anymore (and I cannot in TAI, because months don't even really exist in TAI, since TAI isn't a solar year) in my internal time format, all that convenience goes away. I now must always worry about leap seconds and timezones and all the stuff I don't really need to think about in the vast majority of cases.
…Yeah, well, I'm really not sure. I am not convinced, and am honestly kinda relieved by the fact I won't have to find out. But it's an interesting point nevertheless. And, no, UTC w/o leap seconds is not the same thing. In fact, UTC w/o leap seconds is kinda the polar opposite: it's clearly the wrong abstraction, because it ignores the (not even so hard) problem somebody doesn't want to deal with, which doesn't really go away, but is very practical.
By bloppe 2026-03-1016:52 > This way I know that 14:00 today + one month is still 14:00 in my "internal" time format
Unless there's a leap second in that month. Then it would be 13:59. Maybe you don't care, but some people do. It could have legal or technical ramifications.
> Now, if I cannot really add a month anymore (and I cannot in TAI, because months don't even really exist in TAI, since TAI isn't a solar year).
What do you mean by month? Calendar months are obviously irregular (thanks February). "30 days" makes perfect sense in TAI. Indeed, 14:00 today + 30 days would always be 14:00 in TAI.
