Time Lords decree: No leap second needed in 2024
- Reference: 1720160986
- News link: https://www.theregister.co.uk/2024/07/05/iers_decrees_no_leap_second/
- Source link:
The standards keeping body [1]established that there was not enough difference between time as measured based on atomic clocks (UTC) and time as measured by the Earth's natural rotation (UT1) to warrant making a ripple in time.
UT1 varies thanks to phenomena like gravitational interactions with the Moon and Sun, and geological activities such as earthquakes which alter the speed of Earth's rotation.
[2]
UTC and UT1 therefore might not always match. The IERS maintains a maximum value of ±0.9 seconds by which the two can vary.
[3]
[4]
If that limit is exceeded, various applications that sync UTC and UT1 can strike trouble as time stamps don't align. That's when a leap second is thrown in. If you're interested in the current difference between UTC and UT1, you can check it out [5]here .
Earth's rotation slowed in recent decades, creating a need for 27 leap seconds introduced between 1972 and 2016. Our planet's spin has sped up a little since – which is why we've not had a leap second added for a few years.
[6]
Leap seconds are added to UTC time at the end of December or June, and announced six months before their implementation.
[7]Meta proposes doing away with leap seconds
[8]US reckons it's about time the Moon had its own time zone
[9]Time Lords decree an end to leap seconds before risky attempt to reverse time
[10]It's that most wonderful time of the year when tech cannot handle the date
While a leap second has never been subtracted, doing so is a theoretical possibility and may one day be warranted.
Leap seconds are more than timekeeping trivia – computers must keep up with very precise changes to the way humanity measures time.
Last time a leap second was added, Cloudflare [11]suffered a limited service interruption and [12]Linux servers choked . Systems that rely on precise timing – such as GPS and financial trading platforms – can be affected too.
Meta's engineering team therefore [13]proposed doing away with leap seconds back in 2022. It's an interesting development on many levels – not least that the social network reckons it has enough power to sway a global problem-solving phenomenon.
[14]
But adding leap seconds is a known problem, even if annoying and resource-sucking. As at least one [15]blogger has noted: "No one, or almost no one, is ready for a negative leap second."
It's extremely likely that Meta will get its way and the leap second will become a thing of the past. Back in November 2022 The Bureau International des Poids et Mesures (BIPM) [16]declared 2035 as the year in which the concept will be binned.
The plan is to replace it with a "new maximum value for the difference (UT1-UTC) that will ensure the continuity of UTC for at least a century." ®
Get our [17]Tech Resources
[1] https://datacenter.iers.org/data/16/bulletinc-068.txt
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_offbeat/science&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZofEQrTqwGWlz2Salg5xwwAAAMQ&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_offbeat/science&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZofEQrTqwGWlz2Salg5xwwAAAMQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_offbeat/science&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZofEQrTqwGWlz2Salg5xwwAAAMQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.iers.org/IERS/EN/DataProducts/tools/timescales/timescales.html
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_offbeat/science&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZofEQrTqwGWlz2Salg5xwwAAAMQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://www.theregister.com/2022/07/26/leap_seconds/
[8] https://www.theregister.com/2024/04/03/coordinated_lunar_time/
[9] https://www.theregister.com/2022/11/22/leap_seconds_discontinued/
[10] https://www.theregister.com/2024/02/29/fuel_pump_leap_year_bug/
[11] https://www.theregister.com/2017/01/04/cloudflare_trips_over_leap_second/
[12] https://www.theregister.com/2012/07/02/leap_second_crashes_airlines/
[13] https://www.theregister.com/2022/07/26/leap_seconds/
[14] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_offbeat/science&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZofEQrTqwGWlz2Salg5xwwAAAMQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[15] https://qntm.org/leap
[16] https://www.theregister.com/2022/11/22/leap_seconds_discontinued/
[17] https://whitepapers.theregister.com/
Damn!
There was so much I was planning to do!
Re: Damn!
DOCTOR: That's ages. What if I get bored, or need a television, couple of books? Anyone for chess? Bring me knitting.
SEP error
There are some people who use GPS as a frequency ref and time ref rather than a positioning system.
If Meta's "smeared seconds" proposal is adopted these systems will be broken during the adjustment interval.
The only system I have personal experience of is DVB-T Single Frequency Networks, but there may be others.
Edit: on second thoughts GPS doesn't use leap seconds, but I'm still not in favour of wrong length seconds. It's like those clocks on the Swiss railway that always make sure the trains leave on time by shrinking and stretching seconds. It's just wrong!
Re: SEP error
Edit: on second thoughts GPS doesn't use leap seconds, but I'm still not in favour of wrong length seconds.
Neither are lawyers. Plays havoc with their billing systems.
It's like those clocks on the Swiss railway that always make sure the trains leave on time by shrinking and stretching seconds. It's just wrong!
Railway time can be mildly entertaining and relieve the boredom of standing on station platforms. Train due at 06:38. Train delayed, now 06:58. Train then due at 06:32. So musing about the acceleration and velocity of the train to regain 20mins, and how long the train will be delayed at my station while cleaning crews mop up the remains of the unlucky commuters.
The negative leap second
A new Y2K in preparation ?
I can understand some points, actually. Adding seconds just means that logs write the next operation x seconds after the last. Removing a second would mean that a log (especially transaction logs) would have multiple entries for the same second, and then some more. That could be quite the headache for many servers and RDBMSs, not to mention the admins that keep them ticking.
And I have zero idea how to solve the issue.
Re: The negative leap second
Is it really such a big deal? For logs, etc, you already have the ordering of entry in the storage system that gives you a large degree of causality, and you know exactly when a leap-second is added/subtracted so you know of a specific 1s window when the UTC time stamp might be repeated.
Also many computer systems based on Windows, and some on Linux using crude time-adjustment methods instead of NTP-like daemons, can't keep sub-second accuracy by default so if worrying about remotely logged time you have such issues today.
The only big issue are folks using time-wasting loops, etc, rather than tested library calls for such matters, they might get in to difficulties if time steps backwards. But people test their code don't they? Don't they? Oh...
Re: The negative leap second
I can't see it being a big problem. It's no different to manually setting the clock, or DST changes in some systems.
The much bigger problem will be Y2K38. I'm already planning to be on holiday that week!
Re: The negative leap second
And then,
>>The plan is to replace it with a "new maximum value for the difference (UT1-UTC) that will ensure the continuity of UTC for at least a century."
So, in a century or so, there will be a new pressing problem, because no system will have been prepared for this thing "that happens less than once in a century"
dont be too sure
I have suffered under systems where very high transaction rates required unique ID numbers, generated combination of source companyID, date and time. Absolute local time to millisecond or less, This meant multiple transactions from a single client could have multiple non-unique transaction IDs. Even then sequence numbers based on an integer in memory was required. And daylight saving reversions required a full hour long shutdown of mainframe. Which meant systems feeding it, consisting of multiple layers of applications and OS required an orderly shutdown and start up so no transactions were lost. Took an hour, even when automated, though I think it was down to 20 minutes eventually thanks to some good coding between the Windows and Unix admins. Mainframe programmers, try not to strangle them.
All Because…
…pretty much all the software industry did the stupid thing and settled on UTC for computer time, rather than on TAI which is a hell of a lot easier to handle.
If all computers were set to TAI instead of UTC, and simply ran all software exactly as it is now (ie in ignorance of leap seconds), we’d not have a problem at all. Most people wouldn’t care about the minor offset to UTC or UT1 and those who did could easily sort that out themselves.
For those interested in “proper” time it’s worth a look at the International Astronomy Union’s SOFA library. If that were used in a similar way to how everyone uses tzlib the software world would have no problems.