World's Timekeepers Vote to Eliminate the Leap Second (smithsonianmag.com) 91
Timekeepers have officially voted to eliminate the leap second, allowing Coordinated Universal Time to drift as much as one hour from Earth's rotation before a correction is needed. The change ends decades of occasionally adding or subtracting seconds and replaces it with a hypothetical "leap hour" that likely wouldn't be necessary for hundreds or even thousands of years. Smithsonian Magazine reports: "It's kind of a philosophical discussion, because if a leap hour happens, it won't be for a very, very long time," Christian Bizouard, director of the IERS Earth Orientation Center in France, tells the Guardian's Ian Sample. "What we are doing is pushing back the decision."
The move caps off 30 years of debate, as the leap second has been highly controversial in the world of timekeeping. Leap seconds aren't nearly as smooth of a fix as leap years are, and they can cause computer and website issues. Reddit famously crashed when a leap second was added on June 30, 2012. It's "always been a problem," Judah Levine, a former researcher at the NIST's Time and Frequency Division, tells Scientific American's Emma Gometz.
Instead of adding the entire second all at once, companies such as Google and Meta add the extra time in smaller segments in a tactic called "smearing," according to the Conversation. It's not a simple task, however, and companies that employ smearing have long lobbied to get rid of the leap second. What's more, with Earth's recent spin acceleration, timekeepers around the world were facing the possibility of the world's first negative leap second, in which a second would be subtracted from UTC. This sparked fears, akin to those surrounding Y2K, that our modern technologies wouldn't be able to handle such a change.
"It's never happened before, and therefore the software for that has never been tested," Darryl Veitch, a researcher who leads the Timing Lab at the University of Technology Sydney, tells the Australian Broadcasting Corporation's Ellen Phiddian. But others argued that it wouldn't be much of a problem. The vote means that in the future, UTC will be allowed to diverge from astronomical time more than ever before.
The move caps off 30 years of debate, as the leap second has been highly controversial in the world of timekeeping. Leap seconds aren't nearly as smooth of a fix as leap years are, and they can cause computer and website issues. Reddit famously crashed when a leap second was added on June 30, 2012. It's "always been a problem," Judah Levine, a former researcher at the NIST's Time and Frequency Division, tells Scientific American's Emma Gometz.
Instead of adding the entire second all at once, companies such as Google and Meta add the extra time in smaller segments in a tactic called "smearing," according to the Conversation. It's not a simple task, however, and companies that employ smearing have long lobbied to get rid of the leap second. What's more, with Earth's recent spin acceleration, timekeepers around the world were facing the possibility of the world's first negative leap second, in which a second would be subtracted from UTC. This sparked fears, akin to those surrounding Y2K, that our modern technologies wouldn't be able to handle such a change.
"It's never happened before, and therefore the software for that has never been tested," Darryl Veitch, a researcher who leads the Timing Lab at the University of Technology Sydney, tells the Australian Broadcasting Corporation's Ellen Phiddian. But others argued that it wouldn't be much of a problem. The vote means that in the future, UTC will be allowed to diverge from astronomical time more than ever before.
Do you have the time if I have the energy? (Score:5, Funny)
/sigh
I don't have time for this.
Re: (Score:2)
'Reddit famously crashed when a leap second was added on June 30, 2012.'
Fuck Reddit.
Re: (Score:2)
I remember several sites crashing at that time.
Someone had tested a Linux setup in advance and had triggered a crash, a fix was released. A fair number of sites did not apply the critical fix before it was needed and a fair number of admins had to answer the question "why". One of those sites was Amadeus [amadeus.com] and that affected me so I noticed.
Re: (Score:2)
If I remember correctly, there was a bug in Java which required updating Java to not crash. We worked around it by shutting things down a few seconds before and starting it again after seconds after.
One of the biggest problems with leap seconds is that it's hard to properly test them. We had to install special firmware on a GPS receiver and use that as the NTP source for our servers so we could command the GPS to insert a fake leap second to test them. I'm very happy that they're gone.
Re: (Score:2)
It is actually not hard to test.
A crash from a leap year basically means something went seriously wrong in parsing.
Note: 23:59:60m this is time with a leap second, the 60. Except for leap second, it otherwise always is in the range 0 - 59.
So either the parser throws an exception about getting a number the programmer forgot to exist, or the 60 might be used to index into an array and be off by one, etc.
So, to test it, you basically only need test times with leap seconds.
The second critical part: to convert a
Re:Jail them all (Score:4, Funny)
Ummm, No.
Where did you get that idea?
Maybe from TFS. I don't know, this is Slashdot, we don't read summaries here.
Re: (Score:3)
Maybe from TFS. I don't know, this is Slashdot, we don't read summaries here.
Exactly! We just click the link to get to where we can post our political bullshit instead!
News for Nerds. Stuff that Matters.
Re: (Score:2)
It's not just Reddit. There are two main problems with leap seconds.
1. A lot of software just can't cope with the time being 23:59:60. It's bad enough that Google, for example, extends the length of all the seconds in the hour before the leap second, because that's less problematic.
2. Because there is no way to predict leap seconds, devices have to be updated when they happen. Internet connected devices can pull the information from trusted sources, other devices need offline firmware updates. We know how m
Re: (Score:2)
Although... Industry once spent billions on Y2K.
Are we saying more than a quarter of a century later software engineering practices haven't improved re: testing and formal proofs and AI (sorry, Donald, SI) fuzzing? :)
I'd have hoped right-to-repair legislation would have forced device makers to open unsupported firmware before dumping it as abandonware.
Re: Jail them all (Score:3)
These only sound like similar problems on the very surface. In fact, these two issues are quite different from a engineering perspective.
Y2K was a long term project planning around a single event triggered by a change in format.
This is an ongoing operational change with unforeseen consequences with no widespread events we can rely on to gauge the impact. The types of bugs this type of thing might introduce are subtle, and far more likely to impact security rather than stability.
Re: (Score:2)
Yes. We'll just use AI to fix the problem because all the real engineers will have retired. You trust the future crop of workers to be better then the last, given our educational standards? If so, that's extraordinary leap of faith from my perspective.
Re: (Score:2)
It's hard to properly test leap seconds because NTP tries really, really hard to not diverge from UTC. And your code might work fine but that doesn't matter when the JVM or operating system break underneath you.
Re: (Score:2)
It's less problematic for some applications. It's quite terrible if you're trying to stay synchronized with something like satellite motion, where it's easier to either use one of the TAI-locked times (like GPS Time) or explicitly handle a leap second than it is to handle smeared leap seconds. Stock traders similarly want to be sure they know exactly what the civil time is so they can resolve trades, rather than smearing a leap second over however many hours or days.
Re: Jail them all (Score:2)
Re: (Score:1)
Stock traders may tag data frames with nanosecond timestamps but they didn't rely on UTC to actually resolve trades. It was the arrival order at the exchange that settled it, not what time the clients say they timestamped an event. (Imagine the headache trusting that?)
If you were required to be locked in to UTC to talk to stock exchanges, or are an astronomer, you already weren't affected by smearing, and still won't be after this decision.
Also I'm getting a kick out of the rending of garments and gnashing
Re: (Score:2)
Leap second is far better than leap hour. Google invented leap smear for the leap second because leap smear is subtle enough outside science usage. But you can't do that for leap hour. If you think software system can't cope with leap second, it will be far more difficult for them to cope with leap hour. Those politicians confuse DST vs leap hour and wrongly assume leap hour will be as easy to handle as DST. Or they think human civilization is going to collapse completely before we need leap hour?
Another
Re: Jail them all (Score:2)
We have hundreds or even thousands of years to figure out how to rollout a leap hour. We have about 3 years to figure out how to handle a negative leap second.
Re: (Score:2)
"Hundreds or even thousands of years to figure out" is an illusion. Software and hardware fix budget and planning won't be granted until the situation is close to deadline. Also, currently we pretend leap second doesn't exist in UNIX timestamp and a lot of other internal timestamp format in filesystems. We can't pretend the same when leap hour comes.
If your worry is about how to handle negative leap second, we can explicitly eliminate negative leap second but keep the existence of positive leap second. I
Re: (Score:2)
Keep in mind that the leap hour won't happen for thousands of years, i.e. it's just a fudge to satisfy some legal requirements but in practice it's never going to happen on the timescales that humans can plan for.
Re: (Score:2)
If you have daylight saving time in your country, region, then the software can already handle leap hours.
At least in theory ... as the new leap hour will be probably put at a random place, this of course will have its unique problems.
Re: Jail them all (Score:2)
To be fair if your device isn't connected to the Internet, it almost certainly doesn't matter if it knows the time to the precise second.
Re: (Score:2)
The typical example is something like a GNSS receiver. While many GNSS modules do work with leap seconds, the device itself needs to be able to cope with 61 second long minutes.
How will Jesus find planet Earth? (Score:2)
A microsecond here, a nanosecond there, pretty soon you're talking big time. Now think about it, if you're off by a few milliseconds in terms of the Earth orbiting the galaxy at 515,000 mph that's probably tens of thousands of miles (you do the math, I'll do the implications) .. Now let's assume Jesus had planned to come back on say January 14th, 2100 AD. Where the fuck would the Earth be at that time? Since we didn't account for the microseconds and all that .. the Earth would be like thousands of miles of
Re: (Score:1)
How will Jesus find planet Earth?
I tend to presume the management software has a search function.
Re: (Score:1)
Unfair. If you actually rely on what he is reported to have said, rather than what others have added, he comes off as a good guy (outside of a few lapses, like that fig tree incident).
I happen to think he's as fictitious as Adam Selene, but that's almost irrelevant.
Re: (Score:1)
Cursing a fig tree for being barren was a relatively harmless thing to do. Worse was against the moneychangers in the temple. Jesus had a nasty, violent temper.
Re: (Score:2)
And that's nothing compared to his dad. That dude is guilty of a number of genocides, and his temper tantrums and logic put Lord Emperor Trump to shame. Like, punishing his pet nation for its leader conducting a census that the god himself ordered in the first place.
He asks God. (Score:2)
We are all doomed, I tell you (Score:3)
That's how greatness rots and empires fall.
Re: (Score:3)
UCT also moves backwards *and* forwards continually, mostly due to gravitational variances due to other cele
Re: (Score:2)
Above should have used CUT, not UCT.
Re: (Score:2)
Damnit! UCT != CUT either, which is yet *another* standard timezone, using the same three letters. Cue oblig. XKCD on standards... [xkcd.com]
Above should have used CUT, not UCT.
sir, the obligatory xkcd on time standards is this one:
https://m.xkcd.com/2867/ [xkcd.com]
Re: (Score:2)
It was much ado about nothing ... but in the future no one is going to retain any accommodations. So, when we want to make an adjustment, it will be a Y2K treatment each and every time from now on.
Bunch of idiots made this decision, imho.
Re: (Score:2)
The "leap hour" will just never be implemented. There's no need for it. Just avoid returning to Standard time from Daylight saving time one year, and switch the labels.
Maintenance vs Toil (Score:2)
Between 1958 and 2026 we've added 37 leap second. That's 6616 years before we'd drift a full hour at the rate we've been drifting since 1958. We're currently looking at removing one of those 37 leap seconds. So really it's even longer than 6616 years. If somehow the pace of leap seconds doubles we're still OK for well over a thousand years.
Re: (Score:2)
Re: (Score:3)
If you can put off maintenance for thousands of years it's not really maintenance, it's toil.
Between 1958 and 2026 we've added 37 leap second. That's 6616 years before we'd drift a full hour at the rate we've been drifting since 1958. We're currently looking at removing one of those 37 leap seconds. So really it's even longer than 6616 years. If somehow the pace of leap seconds doubles we're still OK for well over a thousand years.
especially since we'd go back one this time they could've just kicked the can a little down the road by deciding to just ignore this one which likely would've allowed them to ignore the next +1 too...
I'm with OP that once this is gone the systems will just become more brittle.
like imagine what it would be like to implement DST if the computing ecosystem didn't grow up with it.
Re: (Score:2)
So, if we'll be OK for a thousand years, I guess we're destined for a Y3K crisis!
The passing of time... (Score:1)
The passing of time and all of its crimes Is making me sad again
The passing of time leaves empty lives waiting to be filled
- "Rubber Ring", The Smiths
When in Rome, ... (Score:2)
Something does not compute (Score:2)
Ask a mediaevalist about ancient Rome?! Surely they can't have run out of interesting on-topic things to talk about?
Re: (Score:2)
Re: Something does not compute (Score:2)
But the Catholics have assured me they don't count.
Nobody mention TAI (Score:4, Informative)
Now we have two standards that measure the same thing, only with an offset between them.
Re: Nobody mention TAI (Score:3)
So like Celcius and the superior Kelvin
Re: Nobody mention TAI (Score:3)
Celsius
Re: (Score:2)
Ole Christensen Rømer
Re: (Score:2)
Do it in freedom units. Fahrenheit and Rankines.
Re: (Score:1)
Now we have two standards that measure the same thing, only with an offset between them.
Two standards? You're lucky to be so naive. I've had to deal with UTC, TAI, TT, GPS and GLONASS. Also common are UT1 and BeiDou. I almost forgot TDB. When dealing with things beyond Earth it gets even more messy.
Re: Nobody mention TAI (Score:3)
Re: (Score:2)
Most networked time is synchronized for local clock drift constantly, most chips are simply not that accurate, so change the source clock and they won't even need to be fixed as the constant syncing corrects for such a small change automagically.
Re: (Score:2)
Atomic time is based on 9,192,631,770 periods of cesium? why not adjust the period count to not require any leaping? Fix the damn problem at the source and be done with it. This new strategy is just in accordance with the lazy do-nothings. Most networked time is synchronized for local clock drift constantly, most chips are simply not that accurate, so change the source clock and they won't even need to be fixed as the constant syncing corrects for such a small change automagically.
That won't work because the rotation rate of the Earth is not uniform. No matter what you pick for the length of the second, the Earth will not always turn in 86,400 seconds.
Re: (Score:2)
Or we could just put big old rockets around the equator and use them to sync Earth with the scientific 'real time.'
I guess the current new solution is to just let the two time standards drift apart - the problem is that they are so close right no
Re: (Score:2)
I never said to adjust it only once. For scientific use time should be specified as TTTT:TT:TT:TTTTT - PPPPPPPPPP where PPPPPPPP is the periods of cesium per second used for that measurement. For everyday use no need to distinguish the varying time 'constant.'
That was tried before 1972. The frequent adjustments of the length of the second became cumbersome to track, so the in 1972 the switch was made to the current system of constant length seconds with leap seconds to keep UTC tracking the rotation of the Earth..
You will regret that (Score:2)
You will regret that in a few thousand years!
good thing I guess (Score:3)
Re: (Score:2)
When I worked for a broadcasting software company that had customers worldwide, everything was using TC (timecode), PTP, and of course we needed to support leap year, different timezone etc when a broadcast was scheduled between different zone around the world (it can be complicated) ; and we needed to support leap second by contract! Easiest thing was to add a 1s black frame after the schedule after reaching midnight. Supporting negative leap second would have been complicated... Good thing we drop it I think.
That's very interesting.
To support negative leap seconds you can insert one second of black on normal days, two seconds of black on days with a positive leap second, and no seconds of black on days with a negative leap second.
Kicking the can down the road? (Score:3)
Re: (Score:2)
Re: (Score:2)
To me this is a big issue, maybe they should have went for Leap Minute, or maybe something like the ancient Romans did, The day has 86400 seconds and vary the second length based upon day of the year. IIRC, google did something like this years ago.
But why even change, I think all modern OSs solved the Leap Second issue anyway, seems a waste to me.
Re: Kicking the can down the road? (Score:1)
And it's a damn stupid way of doing things if you use civil time as your clock source for things like navigation or rf communication. Because those require seconds and intervals of seconds to actually mean something traceable to the SI second.
Re: (Score:2)
It will be a Y3K crisis.
I'm not sure we'll be ready for the leap hour (Score:1)
If we struggle with leap seconds now I can't imagine how much fun a leap hour is going to be when it happens.
Y2K, 2038 and then the leap hour.
Re: (Score:3)
More info on time âoesmearingâ (Score:2)
TFS and TFA omit the link to The Conversationâ(TM)s article that mentions "smearing" by the big tech companies. That in turn links here [medium.com].
They avoid the catastrophe of repeating the last second of the day (which has time run backwards briefly) by instead extending the duration of each "second" by a few microseconds during the 24-hour period that includes the leap second. I assume thatâ(TM)s short enough that the network time service on individual computers just says "oh, my local clock is running a
Re: (Score:2)
The big problem is there was never a standard implementation of it and systems that really needed to stay in sync to the ms across large areas freaked a bit.
Re: (Score:2)
Re: More info on time âoesmearingâ (Score:2)
They support it because it means they don't have to solve the problem in the next three years. Now they have likely thousands of years.
It's honestly the only sane, rational decision. There's zero benefit to trying to rush out new code to the world in the next three years that might lead to widespread outages and possible security lapses. Especially since this type of code is very hard to test.
Re: (Score:2)
Re: More info on time âoesmearingâ (Score:2)
What's the point of having a leap second if you're not going to actually adjust the clock when it drifts?
Re: (Score:2)
It is always about "how about drift can we tolerate before we adjust the clock".
If the problem of negative leap second is we would have to rush out new code, we can define the leap second scheme to tolerate up to 2 seconds, 3 seconds or even 5 seconds before we have to apply the negative leap second. Then there will be sufficient time to write the new code, meanwhile not *too much* time such that people get lazy and delay the necessary work.
I have a sundial you insensitive clods. (Score:2)
GPS (Score:5, Interesting)
For those crying "YOU'LL REGRET THIS"
Just note that we're ALREADY in this state today.
GPS is 18 seconds off from UTC, right now, today.
Daylight "Savings" Time (Score:2)
Those dolts probably like the idea of standardizing on DST.
Or are they just slowly rebelling against it?
Relativistic Time (Score:3)
By time an hour would be needed we'll have to factor in the relatively different passage of time on various colonies and have a standard that accounts for timekeeping in different reference frames at least throughout the Solar System.
Hopefully ... if we don't allow politicians to kill our civilization first.
Somebody who works that out now and proposes a correct mechanism will have their name remembered.
Talk about enshitification, (Score:2)
The only interesting part of the SFTS time signal broadcast is now gone
oh great another one (Score:2)
Now every hundred thousand years we are going to have slashdot filled with posts saying "the leap second is stupid! It causes accidents and increased stress!" while a wave of others insist we need the leap second or our children will be standing waiting for the bus in the dark.
Re: (Score:1)
In the year 8025... (Score:2)
Re: In the year 8025... (Score:2)
Yeah, we could literally run out of room for the year in some databases before we encounter the leap year.