BIPM decides to stop adding leap seconds to UTC
gliffie
133 points
60 comments
October 15, 2026
Related Discussions
Found 5 related stories in 105.0ms across 9,619 title embeddings via pgvector HNSW
- No leap second will be introduced at the end of December 2026 ChrisArchitect · 265 pts · July 09, 2026 · 61% similar
- IPFS Maintainers Winding Down iand · 340 pts · August 24, 2026 · 34% similar
- Please consider running a NTP server in the NTP Pool robinpie · 36 pts · September 08, 2026 · 34% similar
- US House of Representatives takes step to make daylight saving time permanent throw0101d · 40 pts · July 15, 2026 · 34% similar
- The large robotic arm on the International Space Station has stopped working robin_reala · 16 pts · September 28, 2026 · 33% similar
Discussion Highlights (11 comments)
smartmic
Short: no more leap seconds
jcranmer
TL;DR: No more leap seconds. The replacement will not be leap minutes but leap hours.
frangonf
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.
hnuser123456
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
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, but even then it's unclear if they'll do something). 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, ever. The page lists several good reasons for this, including: - It's a common source of bugs. - Solar time is not that important in a world of coarse timezones. - IoT 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 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. - The proper ISO8601 formatting of leap seconds ("23:59:60") is widely unsupported, breaking parsers, along with the assumption of how many seconds are in a minute, hour, or day. --- EDIT: I've emailed hn@ycombinator.com to change the title. It's avoiding editorialization, but I think it's also preventing the post from getting the attention it deserves. I'm booking a yearly one-second-long holiday on my calendar, to celebrate all the headaches this will save me. Happy end of leap seconds!
neutrinobro
Yay! No more leap seconds to manage! This is going to make my life much easier. Edit...scratch that, now I have to keep track of UT1-UTC as a separately continuously varying parameter provided by IERS instead of tzdata
moezd
After a day of reading AI slop, reading what's essentially an MUN-style resolution, 100% human made, is like eye candy. Thank you for sharing this.
amelius
AI has become real, and we're cancelling the leap seconds? This is unfair. If AI wants to be a coder then it has to do leap seconds. In fact, let's give it leap minutes and leap hours too.
dboreham
Praise the maker.
pushedx
The mechanism that they have proposed to make this a non issue is interesting. It reads to me as if they are asking another standards body who measures the angle of the Earth's axis relative to the Sun to adjust by a small amount so that leap seconds wouldn't be needed for a period of 100 years.
nullc
YYYYYYYYYYYYEEEEEEEEEEEEEEESSSSSSSSSSSSSSSSSSSSS!!!!!!!!!!!!!!!!!!