In 2015 I was working at a "fintech" company and a leap second was announced. It was scheduled for a Wednesday, unlike all others before which had happened on the weekend, when markets were closed.<p>When the previous leap second was applied, a bunch of our Linux servers had kernel panics for some reason, so needless to say everyone was really concerned about a leap second happening during trading hours.<p>So I was assigned to make sure nothing bad would happen. I spent a month in the lab, simulating the leap second by fast forwarding clocks for all our different applications, testing different NTP implementations (I like chrony, for what it's worth). I had heaps of meetings with our partners trying to figure out what their plans were (they had none), and test what would happen if their clocks went backwards. I had to learn about how to install the leap seconds file into a bunch of software I never even knew existed, write various recovery scripts, and at one point was knee-deep in ntpd and Solaris kernel code.<p>After all that, the day before it was scheduled, the whole trading world agreed to halt the markets for 15 minutes before/after the leap second, so all my work was for nothing. I'm not sure what the moral is here, if there is one.
Currently software has to be built to accommodate leap seconds. They happen frequently enough that you'll find out within a few years whether your software breaks when time suddenly skips forward or backward.<p>If we kick the can down the road such that eventually we'll need to add a leap minute, we're going to end up with software that was never written to expect time to change in such a way, hasn't had a real world test of the change for decades, and will have no one working on the software who ever had to deal with such a change.<p>It's going to be much worse for software reliability to have a leap minute on the order of once a century than a leap second every few years.
Hot take…<p>Storing anything as UTC was a mistake and we should be using TAI for all storage and computation, only transforming into more human friendly formats for display to end users. This never needed to be a problem except we decided to make it harder to use TAI than UTC and so everything got built up off the backs of legacy bios level hardware supported UTC style clock behaviour, when we should have been using TAI from the start. Yes I know it would have been harder, but we got off our collective asses and decided to fix our short sighted decision making for Y2K date storage, why not this… if it truly costs as much for everyone to endure a leap second why wasn’t it just fixed from the bottom up and rebuilt correctly!
> The CGPM — which also oversees the international system of units (SI) — has proposed that no leap second should be added for at least a century, allowing UT1 and UTC to slide out of sync by about 1 minute.<p>So, in one century, we'll get 1 minute's worth of drift.<p>Recall that we all share the same clock within timezones, and 1 minute of drift between atomic & solar clocks is the equivalent of traveling 1/60th of your timezone's width to the east or west ... something many people do every day as part of their commute. _Everyone's_ clock deviates from their local solar noon, and _nobody cares_.<p>Put another way: (at most) one north-south line in your timezone will have solar noon & clock noon line up. Over time the relative location of that line will move. Fine. Let's not screw with our clocks in an effort to keep the location of that line fixed.
> Although human timepieces have been calibrated with Earth’s rotation for millennia, most people will feel little effect from the loss of the leap second. “In most countries, there is a one hour step between summertime and winter time,” says Arias. “It is much more than one second, but it doesn't affect you.”<p>I find this off-hand comment dismissive and out of touch. The semi-annual switch from Daylight Savings to "normal" and back again is absurd, and far from not affecting anyone. Studies show that productivity drops for about a week following the change [1], and there is a marked increase in road fatalities after the clocks are adjusted [2].<p>If anything, this leap second business is what's irrelevant to everybody except a handful of obscure boffins.<p>[1] <a href="https://www.healthline.com/health-news/daylight-saving-can-make-driving-less-safe" rel="nofollow">https://www.healthline.com/health-news/daylight-saving-can-m...</a><p>[2] <a href="https://www.boston.com/news/jobs/2016/03/16/daylight-saving-time-made-you-a-lazier-sloppier-worker-this-week/" rel="nofollow">https://www.boston.com/news/jobs/2016/03/16/daylight-saving-...</a>
It seems I've got an unpopular opinion reading the comments here, but having some leap seconds from time to time ensure we are able to manage them.
But "no leap second should be added for at least a century" <i>ensures</i> there will be a y2k reckoning every century. Seems short sighted to me, even if it is not a game-changing issue, let's be honest.
> <i>How, and whether, to keep atomic time in sync with Earth's rotation is still up for debate.</i><p>[…]<p>> <i>The CGPM — which also oversees the international system of units (SI) — has proposed that no leap second should be added for at least a century, allowing UT1 and UTC to slide out of sync by about 1 minute. But it plans to consult with other international organizations and decide by 2026 on what upper limit, if any, to put on how much they be allowed to diverge.</i><p>So everything about this hasn't quite been sorted out yet.<p>At some point there may need to be a reckoning like was done with the calendar:<p>> <i>Second, in the years since the First Council of Nicaea in AD 325,[b] the excess leap days introduced by the Julian algorithm had caused the calendar to drift such that the (Northern) spring equinox was occurring well before its nominal 21 March date. This date was important to the Christian churches because it is fundamental to the calculation of the date of Easter. To reinstate the association, the reform advanced the date by 10 days:[c] Thursday 4 October 1582 was followed by Friday 15 October 1582.[3]</i><p>* <a href="https://en.wikipedia.org/wiki/Gregorian_calendar" rel="nofollow">https://en.wikipedia.org/wiki/Gregorian_calendar</a><p>As annoying as handling a leap second could be, if it happens even somewhat regularly it can be testing more often. Deciding in the future to do a 'one-off' event may be more challenging from both a coördination point of view, as well as trying to handle a rare event correctly in (e.g.) code.
The full resolution can be found here <a href="https://www.bipm.org/documents/20126/64811223/Resolutions-2022.pdf/281f3160-fc56-3e63-dbf7-77b76500990f" rel="nofollow">https://www.bipm.org/documents/20126/64811223/Resolutions-20...</a>.<p>To quote the relevant section:<p>> [the CGPM] decides that the maximum value for the difference (UT1-UTC) will be increased in, or before, 2035<p>> [CGPM requests that the ITU] propose a new maximum value for the difference (UT1-UTC) that will ensure the continuity of UTC for at least a century<p>I think there are a few possible interpretations of this:<p>- We'll readjust UTC in a century (why would you do this to yourself, please no, nobody wants this) by setting a predicted maximum that'll last 100 years<p>- The maximum is now 1 hour, we'll adjust clocks the same way we adjust for DST<p>- The maximum is infinite, UTC is now TAI + the same integral offset forever<p>I'm hoping for the last one, but who knows. They've once again kicked the can down the road to the next 2026 meeting to decide what the increase in max UT1/UTC difference will look like.
Why use leap seconds at all?<p>Our current calendar was introduced in 1582, 440 years ago [0].<p>We add a leap second about every 1.5 years [1].<p>That means in the time since our calendar was invented, we've added less than 5 minutes to our time.<p>Would anyone notice if noon arrived 5 minutes earlier over the course of 500 years? Especially since the position of the sun varies orders of magnitude more than that simply based on season?<p>Maybe we could all just agree to add 10 minutes in 3022. If we haven't switched calendars again.<p>[0] <a href="https://en.wikipedia.org/wiki/Gregorian_calendar" rel="nofollow">https://en.wikipedia.org/wiki/Gregorian_calendar</a>
[1] <a href="https://www.timeanddate.com/time/leapseconds.html" rel="nofollow">https://www.timeanddate.com/time/leapseconds.html</a>
How is this supposed to work? The rotation of the earth is not a constant. So we either scrap UT1 ("the atomic clock") or UTC ("the calendar"). Neither sound like an actual option. The latter would imply that at some (far off) point in the future you wake up at like 10pm as UTC and UT1 are now entirely mismatched (you may as well get rid of all time zones at that point).
I don't understand why this is necessary. We already have TAI (international atomic time) which is just UTC without leap seconds. It sounds like this committee voted to stop adding leap seconds to UTC, but not to "reset" the leap seconds that have already been added, effectively cementing a constant difference between UTC and TAI. What is the point?<p>Anybody who cares about leap seconds should have just been using TAI all along instead of UTC anyway.
Hot take: Leap seconds caused by astronomers refusing to modify their own software, instead getting the rest of the world to modify theirs. Too facile?
Google does "leap smearing" which seems like the best human solution to this problem:
<a href="https://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html" rel="nofollow">https://googleblog.blogspot.com/2011/09/time-technology-and-...</a><p>standardizing leap smearing algos and constants could work<p>-Bottom layer is atomic clock seconds
-We define targeted relationship between current UTC and atomic counter that will occur on a given day and time X
-Time is interpolated to drift UTC into place by the given day and time X
-Standards body can adjust time on some regular basis by its relationship to the atomic clock and publish the algo to convert from atomic to UTC
Hurrah!<p>Each leap second event causes hundred of millions of dollars worth of disruption and that's not including the disruption created by leapseconds even when they're not happening (e.g. the frequent false leap seconds) or the mini-disaster we're sure to experience should there be a negative leap second (which we are still trending towards).<p>The delays are unfortunate because it's harder to transition applications that need UT1 to use an offset from UTC when the available time sources are still unpredictably and unreliably leaping on you (since to apply a UT1 correction you need your UT1 offset and your UTC source to agree if and how a leap second has been applied).<p>From a practical perspective it would be better to immediately discontinue leaping, then UTC would immediately become a stable time that adjustments could be applied against for those few applications that need them. It would also save us from a negative leap second.
So we make things worse for humans in order to make it easier for computers?<p>Yah, one second doesn't matter, but it builds up.<p>This: "Or we could even decouple our sense of time from the Sun entirely, to create a single world time zone in which different countries see the Sun overhead at different times of day or night."<p>Shows that they are completely disconnect from human reality: "Science already doesn’t use local times, we talk in UTC."<p>That's great for science, but people care about day vs night.
It's (less than) a minute a century -- why would we not simply say "no corrections except at the century mark, in the middle of the weekend closest to January 31st"? That way:<p>There's an exact time everyone knows the correction will happen, it's just a question of how big the correction will be.<p>The correction is always in the same direction -- no "one second forward, then later one second back" shenanigans.<p>It always happens over a weekend, so no one has to deal with real-time work-time issues.<p>While maybe some have to work a weekend, at least it's not near the year-end holidays.<p>It only happens once every 100 years.
> Or we could even decouple our sense of time from the Sun entirely, to create a single world time zone in which different countries see the Sun overhead at different times of day or night.<p>A very interesting idea, but probably much too progressive.
I've heard of the endless disruption that leap seconds cause for years and only now have I thought to ask the question: what was so important that the entire world needed to add or subtract individual seconds from the calendar? Seems like you'd need a pretty big justification for something like that, but I only here the horror stories, not what the leap second was supposed to actually solve.
I wonder: Why is Daylight Savings/Normal Time not implemented using monotically increasing hours? Day goes up to hour 23 one time of year and hour 25 the other instead of doing a clock hour <i>twice</i>. Would be weird to be able to have 23-hour and 25-hour days. But this seems to be how leap seconds are handled (one 61 second minute)?
The first real program I wrote was a forum in perl. But I didn't want to use "advanced" features like "use" (perl's word for importing a module). It just seemed too magical.<p>So, I had limited time manipulation capabilities. I tried to write all the date handling stuff by hand (with a lot of "if" statements for the special cases). I recall trying to make leap seconds work, but not sure if I actually did. It worked well enough for my purposes.<p>Also, no database, so I did it all with flat files. Worked better than you might expect (thanks to built-in flock()), but I wouldn't recommend it.
The same CGPM 2022 conference also resolved to give standard prefix names for 10 to the 27 and 30:<p><pre><code> power prefix symbol
10^27 ronna R
10^−27 ronto r
10^30 quetta Q
10^−30 quecto q
</code></pre>
c.f. <a href="https://www.bipm.org/documents/20126/64811223/Resolutions-2022.pdf/281f3160-fc56-3e63-dbf7-77b76500990f" rel="nofollow">https://www.bipm.org/documents/20126/64811223/Resolutions-20...</a> (Resolution 3, English version on page 23)
We have a GPS time server (so stratum one) that is set to GPS time, so it's off from UTC by almost twenty seconds because they don't ever apply leap seconds. I love it. Another part of the org pressed me to correct my time to match UTC, but I'm so happy to be done dealing with time changes that I just replied "monotonic time" until they got their own. A few grand to not have those problems is such a bargain!
I never really understood why we need leap seconds. Or better: why we need to bother with them in a computer system at lower level.<p>If we decide that we absolutely need to keep our time in sync with the rotation of the earth, really what should be done is define a timezone with all the leap seconds applied, and use that timezone to only display it to the end user. Not change the way we sync computer clocks for no reason! NTP shouldn't contemplate leap seconds, for example...
There has been a proposal in the 1950s to the UN by a German mathematician to replace the current calendar by a decimal-based system, in which leap YEARS are not needed either: everything would be divisible by 100. I can't remember where I heard this from, but the anecdote goes he got a reply saying thanks for the proposal, but it is not feasible to introduce such a massive change globally, irrespective of the proposed improvements.
> Leap seconds aren’t predictable, because they depend on to Earth’s natural rotation.<p>This is surprising to me. Is the Earth's rotation so arbitrary?
They suggest world wide UTC, saying that the hours of noon, sunset, and sunrise don't really matter. But the real problem of UTC around Australia isn't the hours but the date.<p>It is really convenient that the date changes whilst we all sleep. It makes 'today' and 'tomorrow' weird.
There was talk of REMOVING a second soon because the Earth's rotation had sped up a bit. Physicists havent figured out the cause of the speed up. The previous slow downs were attributed to tidal friction and global warming (expanding seas and atmosphere).<p><a href="https://www.forbes.com/sites/jamiecartereurope/2022/08/03/do-we-need-the-first-ever-drop-second-a-new-wobble-by-earth-caused-the-shortest-day-since-records-began-say-scientists/" rel="nofollow">https://www.forbes.com/sites/jamiecartereurope/2022/08/03/do...</a>
Can anyone explain what the alternative is? Surely we won’t just get more and more out of synch with the earths orbit?<p>Also why does it say the earth is slowing down but this year it sped up. Sounds quite impossible?
Most systems rely on network time from a canonical time source. Wouldn't it be enough to do the leap second smearing/adjustment there to free the end systems from dealing with that?
I love how "the world" voted to end the leap second, before actually coming up with how to deal with scientific desync (Real world: irrelevant. Space science: kinda important)
I trust we will also be getting rid of leap years: that whole pausing the calendar for a day thing is very confusing.<p>Oh wait, that's not how it works. And neither is it how leap seconds work.
Note that what the article actually says is that there will be no more leap seconds <i>starting in 2035</i>. There could easily still be more before then.
Imagine how we would feel if we adjusted lat-long definitions instead of smearing or leaping time in order to adjust for the slowing down of the rotation of the earth.<p>Does that sound bananas to you?<p>Of course it is. That's what we're doing with leap seconds. Only some people smear and some people leap and they don't even do it over the same time or in perfect synchronicity.<p>Just ditch the leap seconds. They are not worth the cost.
Suggestion:<p>Move what is leapsecond independent to UT1, the atomic clock basis -- google, finance, etc now happy<p>Keep UTC etc as is, since offests happen all the time to every other human clock anyway for political or summer time or country boundary changes anyway -- everyone else happy<p>And calculating UTC as offests from the consistent base of UT1 sounds like the way to do it
Well that didn't long, did it? It was introduced in 1972.<p>In years to come historians will be having a good old chortle about how we managed to come up with two times that were 37 seconds apart.<p>In retrospect, fiddling with computer clocks like that was bound to be a nightmare.
I've never really understood why smearing the leap second is such a big deal. Surely if you have software that is going to be sensitive to small variation in the clock over 24h, you're already not using wall time.
I wonder if the idea of giving an irregular offset at regular intervals is in the cards. Having a unknown offset of x seconds every century, say, seems easier to implement than a known offset every unknown interval.
It seems odd to me that they decision was to not solve it this way, but not how it will be solved going forward. Like, doesn't that effectively make everything <i>more</i> complicated/difficult?
whoopie. Can we get rid of daylight savings time? That one actually kills people<p><a href="https://www.newscientist.com/article/2344401-annual-us-clock-change-kills-33-people-and-36500-deer-in-car-crashes/#:~:text=Moving%20to%20daylight%20saving%20time,costs%20annually%20in%20the%20US" rel="nofollow">https://www.newscientist.com/article/2344401-annual-us-clock...</a>.