Time Lords decree: No leap second needed in 2024 The International Earth Rotation and Reference Systems Service (IERS) announced on Thursday there will be no leap second added to 2024. The standards keeping body 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 …
…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.
I've worked on software that cared about the difference... And frankly anyone who's in that situation probably needs to be using UT1 anyway, so having computer clocks on UTC doesn't actually help. We've got too many damned time systems on this planet. And of course things get worse when you leave the planet...
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!
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.
>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!
Not quite. The famous Swiss railway clocks run slightly slow and then wait for a 1/min sync pulse to start the next minute.
The Swiss deal with late running trains by simply renaming whichever station the train is currently at, to the destination.
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.
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...
>For logs, etc, you already have the ordering of entry in the storage system that gives you a large degree of causality
That's no longer the case with systemD lurking around. When you list out the contents of the system journal ('journalctl'), it sorts the log entries by time stamp. If you've got a system such as a Raspberry Pi, which doesn't have an RTC, and therefore doesn't know the real time of day when it's making some early log entries whilst booting up but acquires network time midway through, the resultant log of the boot process is very confusing.
Almost no computer system or software implements UTC properly. The rules all follow are actually those of the TAI timescale (which has no leap seconds), not the UTC timescale (which does).
Accurate timestamps do matter for logging, if there is the possibility that such logs will form part of a court case. If your logs show X did Y at time Z, but you cannot reasonably demonstrate the log's alignment to UTC, then the miscreant X can reasonably say, "I wasn't there at time Z, so I can't have done Y could I?" and you've no admissable evidence. Really, your logs need to log time synchronisation occuring to a demonstrably reliable reference, so that the reliability of the other entries' timestamps is clear.
In different countries that is to different references; in the UK, it's best if you can prove synchronisation to MSF (the "Rugby" radio clock) and not GPS; GPS time is 13 or so seconds off (leap seconds). GPS may or may not be telling you UTC time, depending on whereabouts in its boot sequence the GPS receiver is (the almanac data which tells the receiver what the GPS-UTC offset is takes a while to downlink from the GPS satellites). The offset is big enough that it could make the difference between bad event Y happening and CCTV records showing the miscreant outside (but only just outside) the building. If your company computer network isn't logging its time synchronisation, and the company CCTV or pass entry system isn't either, it is possible for the miscreant to sustain an argument for having been outside the building even if they'd really been inside, pressed <return> on "format c: /s", and darted from the building.
"... Accurate timestamps do matter for logging, ..."
"... That's no longer the case with systemD lurking around. ..."
At least on Linux systems, timestamps are in seconds since epoch. With 64-bit systems, that brings up the Y2K38 issue, but it's expected that hardware will move from 64-bit to 128 bit systems by then, so the issue can be punted down the road again.
What this means is the system clock always increments. It's then converted using the datetime library to the appropriate local display time.
Logging is kept using system clock time, then converted to readable time when displayed. As long as the printout includes a system time column next to local time column (that could be UTC), then there is no ambiguity - the display time column could then be legally argued that the difference is due to physics rather than invalid readings.
"then the miscreant X can reasonably say, "I wasn't there at time Z, so I can't have done Y could I?"
We're talking about seconds, not hours or minutes. I can see an extremely easy reply of "The CCTV time is +/- 20 seconds, and clearly indicates your presence within that range." If it was 10 minutes, that's different.
In all but a very few (real-world) cases, a minute off makes no difference. For logging, having the entries in order is usually more valuable than having them match a particular time standard.
It all depends on the exact physical circumstances. The point is, it's difficult to prove "that's impossible, ergo they are guilty". You have to prove your case beyond reasonable doubt.
A minute off is fine, if you can prove it was a minute. If you cannot, then the log data is essentially worthless (because there's no proof that it's even aligned to the same day). If there's no evidence that the log timestamps are correct or correctable, then you can't even sustain that an event happened on a particular day. It's also no good checking later and saying, "the NTP client is still running", because that's not contemporaneous. Courts are very big on contemporaneous notes, logs, etc. Stuff identified after the event doesn't wash.
The issue is that if a defence question can show that you're "making it up" in one aspect of your evidence, then they will discredit you before the jury (that is if the judge doesn't direct the jury to discount your testimony altogether). This is somewhat mixed up with the laws around computer evidence that - presently - state that unless a system admin knows there to be a bug then the computer evidence is taken as correct. Wrong, or doubtful timestamps are an easy way of discrediting the system admin and the whole IT system (especially after "computer says so" has been severely dinged by the Post Office scandal).
I've seen this sort of stuff go wrong as a juror. I've seen someone get acquitted of a charge of theft of a book, because the prosecution (despite a lot of physical and witness testimony about the theft) couldn't show that a purchase hadn't happened, despite the shop's till records, the stock card still being in the book, etc. Essentially, no one spotted the guy in the act, and it came down to the fact that shop till record couldn't be shown to be infallible, made worse by the shop keeper's admission that sometimes they'd forget to take the stock card out at the point of sale. This one didn't even require the judge to intervene, the prosecution barrister (who by this time looked very fed up) asked for an adjournment and afterwards the accused was found not guilty by the direction of the judge.
Two lessons: 1) your evidence has to be pin sharp in all respects, 2) always insist on a jury trial where the evidence gets a rather more thorough going over, 3) it's very easy to perjure yourself with your own assumptions and acceptances of "normal".
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"
"Removing a second would mean that a log (especially transaction logs) would have multiple entries for the same second, and then some more."
I may be wrong, but I don't think it works like that (or is not supposed to).
A "negative" leap second means one particular minute has 59, instead of 60, seconds.
For example, if it happened right now (13:04 on my clock), you would get:
13:04:57
13:04:58
13:05:00
13:05:01
In theory, good systems (modern RDBMSs and OSs) should know in advance that 13:04:59 isn't happening, just like the 30th of February, and therefore not log anything.
If you DO have stuff in your logs for that time, then yes, it's a headache, and probably means everything between then and the next NTP synchronisation is suspect (probably needing decremented by 1 second).
This post has been deleted by its author
"Someone, somewhere will have a loggable event at 13:04:58.99999 to the limit of precision of the clock."
This is like saying "Someone, somewhere will have a loggable event on the 30th of Februrary", something which can only happen if your calendar is wrong.
The point is that the clock in the system which is logging these events SHOULD never actually read 13:04:59 dot anything, and if you have such entries in your logs, something has gone very wrong.
This is an area for which the code in the libraries needs to be correct, and people should regard writing their own time/date code with as much trepidation as they would writing their own cryptography code.
This post has been deleted by its author
UTC works this way:
1 leap second, on either 31/12 or 30/6:
23:59:57
23:59:58
23:59:59
23:59:60
00:00:00
There can be 2 leap seconds too:
23:59:57
23:59:58
23:59:59
23:59:60
23:59:61
00:00:00
and an anti leap second:
23:59:57
23:59:58
00:00:00
However, most OSes and software has no idea this is happening. So Windows goes:
23:59:57
23:59:58
23:59:59
00:00:00 (wrong)
00:00:01 (wrong)
.
.
01:13:15 (wrong)
01:13:16 (wrong, but now randomly does an NTP update)
01:13:16 (right)
Linux armed with NTP and connected to a leap second aware NTP server:
23:59:57
23:59:58
23:59:59
23:59:59 (wrong, but knows it)
00:00:00
Google and (I think) Facebook want:
00:00:00 (midnight before the leap second)
00:00:01 (wrong, because they have redefined how long 1 second is)
00:00:02 (wrong, because they have redefined how long 1 second is)
.
.
23:59:57 (wrong, because they have redefined how long 1 second is)
23:59:58 (wrong, because they have redefined how long 1 second is)
23:59:59 (wrong, because they have redefined how long 1 second is)
00:00:00 (right, because of the slippage over the past day)
00:00:01 (right, because they've reverted to 1 second = 1 TAI second.
but for some reason Facebook couldn't make this work for an anti-leapsecond (they were predicting total destruction of their systems, an outcome I couldn't see any problems with...).
All of this could be solved if all IT / comms simply opted for a grand global "Switch to TAI" day, as pretty much all software works to TAI's timescale rules, not UTC's. If that happened, then calculations of time differences between recorded time events either side of the switch over would be in error by 37 seconds (the number of leap seconds since they were invented). But almost no one is going to care about that. The thing is that going forward, software, records and time difference calculations would be correct w.r.t. TAI's rules and current value, with no software changes anywhere.
The present situation is in effect already "let's do that", without the jump from UTC to TAI, but maybe some big jump in UTC later on. Let's do it just once.
Time is Fricking Complicated
TAI isn't perfect either, though the imperfection is nearly negligible. The current "second" is different to that used in TAI's earlier days, back in the 1970s. When they first had the idea of a network of synchronised atomic clocks around the world, they soon noticed the clocks diverging. They'd forgotten the reletavistic effects (Einstein!) on clocks being at different altitudes, and therefore being at different depths into the Earth's gravitational well. They corrected for that, but the net result is that the length of 1 second changed slightly for some people. What this means is that I cannot easily calculate to the nanosecond in today's seconds how old I am (being born before this correction to TAI). It also means that, whilst your atomic clock is capable of telling you what the time is at the reference altitude (sea level), your clock (at the top of a mountain) isn't running at that rate and isn't telling you that time... And when one has finished factoring general relativity into timekeeping properly, things get very complicated (IAU SOFA PDF).
They put in the 2 leap second rule for in-case, if for some reason observations of the earth's rotation didn't happen for a spell and we needed a bigger correction when observations resumed.
They only put in the anti-leap second because someone said they ought to, but at the time there was no notion that it'd ever be needed. However, since the 4th June 2020 the earth's rotation has speeded up (though it's clear that angular decceleration was declining starting as far back as 1999), and we've been headed towards needing an anti-leapsecond ever since to keep UTC aligned within 1 second of UT1.
No one knows the means by which the earth's rotational speed can be increased. It's possible that just 1 anti-leapsecond in the ruleset for UTC could be insufficient!
All of this is somewhat arbitrary. The UTC rules were not really designed around software / computers, but around human processes of setting your watch manually. Really, we should allow computers / software to work in TAI (presented in local time zone), and if anyone really cares leave it up to the consuming application to convert the TAI time understood by computers, applications and records into UTC.
When they subtract a leap second they'll just skip one, so that won't be a problem for logs.
Where it might be an issue would be if e.g. you had set a daily job to start at 23:59:59 which wouldn't because that time would not occur. It would be like having a yearly task you always perform on February 29th.
But I think anyone who sets a daily job to start at 23:59:59 or a yearly one for February 29th is just asking for the computer gods to give them a dose of humility!
Time zones.
23:59:59 is 08:59:59 in JST for example and it’s just possible you want something to happen at that time.
The scheduling system should be working on deltas from now to the next scheduled wake-up. Waking up late isn’t an error it just means things got a bit busy in between but the job should still run. You shouldn’t expect the wake up to be exact at least not on a general purpose OSes.
It’s conventional leap seconds that cause the mess because you wake up slightly early if the current interval spans the leap second. That’s not usually expected. Once you get past it then things settle down again.
That said our trading system that did have very important things to do around 9am wasn’t observed to have behaved badly last time a leap second was inserted.
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.
A company I used to work for had a system where everything was logged in local time (uk), this meant that when the clocks changed they would pause the machine for an hour to avoid any logging issues - as this was pre internet working and the offices were closed it didn’t cause much of an issue.
Then some clever person suggested running the machine in UTC and applying al time offset to the users workstations….
Mind you this is the group of people that for years insisted they couldn’t use dns because it slowed the machine down to much.
Said machine in both cases was at the time one of the largest IBM as400 / system I / I series in the country.
The article is weird on this. FB IS big enough to have a seat at the table where the decision is being made. And they DO have a very good point. G agrees with this point.
Although, really, it's all silly to talk about there every being a (computer) leap second. Oh well, it keep folks employed.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
