# Leap seconds are history **URL:** \ **Category:** Server operators\ **Created:** [October 15, 2026, 4:01pm UTC](https://community.ntppool.org/t/leap-seconds-are-history/4788 "2026-10-15T16:01:42Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![MagicNTP](https://avatars.discourse-cdn.com/v4/letter/m/858c86/32.png) [@MagicNTP](https://community.ntppool.org/u/MagicNTP)\ **Post date:** [October 15, 2026, 4:01pm UTC](https://community.ntppool.org/t/leap-seconds-are-history/4788/1 "2026-10-15T16:01:43Z")
The 28th meeting of the General Conference on Weights and Measures (CGPM) today adopted a resolution that abolishes the leap second. > **[Resolution 5 (2026) - BIPM](https://www.bipm.org/en/cgpm-2026/resolution-5)** As there is no leap second scheduled for the end of 2026, it seems that there will be no more leap seconds added or subtracted going forward. That does not resolve the issue of astronomical time, UT1, and UTC based on atomic time TAI, diverging as Earth keeps wobbling around. It just kicks the can down the road by several centuries hopefully by allowing the difference between the two, |UT1 - UTC|, to grow up to 1 hour effective 20 May 2027, compared to the currently allowed 0.9 seconds. ---
**Author:** ![santiago](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/santiago/32/2200_2.png) [@santiago](https://community.ntppool.org/u/santiago)\ **Post date:** [October 15, 2026, 4:22pm UTC](https://community.ntppool.org/t/leap-seconds-are-history/4788/2 "2026-10-15T16:22:13Z")
I’m an astronomer myself, what the actual f\*\*\*?? Are they afraid of a negative leapsecond? Best regards ---
**Author:** ![MagicNTP](https://avatars.discourse-cdn.com/v4/letter/m/858c86/32.png) [@MagicNTP](https://community.ntppool.org/u/MagicNTP)\ **Post date:** [October 15, 2026, 4:30pm UTC](https://community.ntppool.org/t/leap-seconds-are-history/4788/3 "2026-10-15T16:30:39Z")
> [@santiago](#): > > Are they afraid of a negative leapsecond? Industry and other stakeholders are. Even positive leapseconds are an issue. And as consequence, the keepers of UTC are unhappy about the different ways tech companies try to work around any potential technical issues by using leap smearing, in different ways, diluting the concept of a global UTC and SI second. See the “noting that” section of the resolution. ---
**Author:** ![Bas](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/bas/32/465_2.png) [@Bas](https://community.ntppool.org/u/Bas)\ **Post date:** [October 15, 2026, 4:53pm UTC](https://community.ntppool.org/t/leap-seconds-are-history/4788/4 "2026-10-15T16:53:04Z")
If you read why they ditch it, it get’s more stupid: > **[Leap seconds have righted global clocks 27 times. So why do timekeepers want...](https://edition.cnn.com/2026/10/13/science/leap-second-elimination-time-standard)** > > An international meeting is considering a fundamental change to timekeeping, potentially severing the ancient link between time and the motion of the Earth. It’s about money and computers that can’t cope. > The extra second crashed [Reddit and LinkedIn](https://www.wired.com/2012/07/leap-second-bug-wreaks-havoc-with-java-linux/) and [knocked out Qantas’ booking system](https://www.itnews.com.au/news/qantas-outage-pinpointed-on-leap-second-linux-bug-307379) in 2012. And when the most recent leap second was added at the end of 2016, customers of cloud computing [provider Cloudflare](https://blog.cloudflare.com/how-and-why-the-leap-second-affected-cloudflare-dns/) briefly experienced outages or delays after its servers failed to handle the introduction of a leap second properly. Big tech players such as Meta have been calling for its demise, describing the leap second as [“a major source of pain.”](https://engineering.fb.com/2022/07/25/production-engineering/its-time-to-leave-the-leap-second-in-the-past/) I rather wished they would ditch daylight savings instead 🤣 ---
**Author:** ![NTPman](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ntpman/32/450_2.png) [@NTPman](https://community.ntppool.org/u/NTPman)\ **Post date:** [October 15, 2026, 5:08pm UTC](https://community.ntppool.org/t/leap-seconds-are-history/4788/5 "2026-10-15T17:08:03Z")
> [@Bas](#): > > I rather wished they would ditch daylight savings instead If the daylight saving is abolished the very old-old problems will surface again, those, that were among the driving forces to introduce the DST at the first hand. Two generations time is needed in between switching on and off the DST. That way nobody would remember any more the old arguments against the recently planned switch. ---
**Author:** ![Bas](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/bas/32/465_2.png) [@Bas](https://community.ntppool.org/u/Bas)\ **Post date:** [October 15, 2026, 6:38pm UTC](https://community.ntppool.org/t/leap-seconds-are-history/4788/6 "2026-10-15T18:38:59Z")
This post was flagged by the community and is temporarily hidden. ---
**Author:** ![avij](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/avij/32/197_2.png) [@avij](https://community.ntppool.org/u/avij)\ **Post date:** [October 15, 2026, 7:38pm UTC](https://community.ntppool.org/t/leap-seconds-are-history/4788/7 "2026-10-15T19:38:52Z")
One consequence of this decision is that there will be no more leap second smearing either. Therefore it should now be safe to use NTP servers from - [Google](https://developers.google.com/time) (time.google.com) - [Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configure-time-sync.html) (time.aws.com) - [Facebook](https://engineering.fb.com/2020/03/18/production-engineering/ntp-service/) (time.facebook.com) as upstream NTP servers for pool NTP servers. My server in the Philippines now uses Facebook’s NTP server as its primary time source. It’s less than 1 ms away, which is nice. ---
**Author:** ![Bas](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/bas/32/465_2.png) [@Bas](https://community.ntppool.org/u/Bas)\ **Post date:** [October 15, 2026, 8:31pm UTC](https://community.ntppool.org/t/leap-seconds-are-history/4788/8 "2026-10-15T20:31:45Z")
Are you sure? As many PPS-SAT’s won’t agree with you. Does GPS follow? Does Galileo follow? Does Glonass follow? They all apposed to it. What about old software? I doubt it will be this simple. Or if it will make it. As the calibration-point is taken away from exact time. So how do we calibrate now? Against what? Is there a fixing-point? ---
**Author:** ![avij](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/avij/32/197_2.png) [@avij](https://community.ntppool.org/u/avij)\ **Post date:** [October 16, 2026, 3:29am UTC](https://community.ntppool.org/t/leap-seconds-are-history/4788/9 "2026-10-16T03:29:19Z")
I’m not sure I follow you. Unlike leap days, which happen every 4 years except every 100 years except every 400 years, leap seconds were added as needed. By international convention, the French Earth Orientation Center of IERS has had the authority to announce whether there will be a leap second at the end of June or December around half a year in advance via their Bulletin C. [See the latest one](https://hpiers.obspm.fr/eoppc/bul/bulc/bulletinc.dat). Now, what changes is that the IERS will no longer announce that there will be a leap second. Previously, the GNSS operators and all the relevant stakeholders had to incorporate IERS leap second information to their systems whenever it was due, but now they simply don’t need to do anything. The code paths in old software that took care of leap seconds will remain dormant, ie. those parts of code will never be run from now on. Specifically for NTP, the “leap indicator” bits in NTP responses will not be set from now on, and NTP clients will no longer receive indications of an upcoming leap second. Therefore the “old software” point is moot. The GNSS operators were NOT opposed to this change. All they want is a stable continuous timescale. That’s why GPS uses its own [GPS time](https://timetoolsltd.com/gps/what-is-gps-time/) (does not use leap seconds), which is not the same as UTC (used leap seconds) or TAI (International Atomic Time, does not use leap seconds). It is the astronomers who would like to keep UTC synced to the rotation speed of our planet, not GNSS operators. ---
**Author:** ![ask](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ask/32/907_2.png) [@ask](https://community.ntppool.org/u/ask)\ **Post date:** [October 16, 2026, 4:18am UTC](https://community.ntppool.org/t/leap-seconds-are-history/4788/10 "2026-10-16T04:18:16Z")
Great to be done with leap seconds now (unless there’s a rude and disappointing December surprise?) rather than in 2035. There’s no practical situation where the 1 second alignment with the sun (compared to where? certainly not from my house! You need lookup tables anyway) matters, but as an industry we were very very bad at making software that dealt with this properly. How much software knows about the time 23:59:60? How many weird system bugs did we find when there was a leap second after none for a while? GPS hasn’t ever used leap seconds, as @avij said, but the supported they had in the protocol for them led to bugs in GPS receiver chips and time software over the years.