That would create much more chaos, because every region autonomously decides on its timezone(s). You'd have different countries and/or timezones using different leap second counts.
Yes! I yearn for the day when central daylight savings time is 1:00:00:36 behind eastern time, but standard central time remains offset by 1 hour exactly (except for leap years, which are obviously 1:00:00:36 offset all year round).
They're cool people but like it doesn't stop the world from imploding. Most of all of our code is full of trivial bugs and edge cases and most people don't mind too much. Certainly no one cares about leap seconds, they hardly even notice DST or leap days
What causes the unpredictability in this? I would have guessed we have earth's rotation and orbit down to many decimals. Does geological activity, weather, or something else cause rotation speed differences that we just can't predict?
Quite the opposite. The earth's rotation can vary by quite a few seconds each year. But over hundreds of years, the variations mostly cancel out, which is why I think trying to add or remove leap seconds are a bad idea. The only people who care about such things are space agencies, and they can apply whatever offset they want, it doesn't need to affect everyone else.
Arguably, the only real-world impact this drift has on normal people is GPS, but GPS already transmits an offset from its own clock so that receivers can correct for that. The GPS clock is different both from UTC and TIA.
This announcement is very much a nothing burger; it’s already been more or less decided that adding leap seconds just isn’t going to be a thing anymore (in our lifetime). Here’s on article from 2022: https://www.timeanddate.com/news/astronomy/end-of-leap-secon...
Yes, time() and clock_gettime(CLOCK_REALTIME) results are affected by leap seconds.
New leap second will get to your system through NTP. Sadly NTP only distributes indicator flag that leap second is going to be introduced, but not the offset itself. But the distributed time itself is already affected by leap second, so NTP client doesn't really need to know.
(In contrast the other time sync mechanisms - GPS and PTP - use time scale unaffected by leap seconds and distribute it as an additional information with UTC offset. And it's left on client to modify received time on its end. Kernel has a parameters in clock_adjtime() for leap seconds.)
So if you have a passive system that has NTP client then it's time will change for new leap second on runtime. Linux treats UTC time as the dominant one, so that's the one saved to RTC device and will survive reboot.
There is CLOCK_TAI that sounds like it should return TAI time, but it is such a second class citizen to the point that nothing on regular Linux desktop and server distros even set the offset and it returns the same time as CLOCK_REALTIME.
There is a file in /etc with list of leap seconds that is part of some package, so you need to update the system to update this file. I don't believe traditional NTP software updates this package dynamically. But not many software uses it. If some init service script parsed and set the kernel UTC offset then your system's CLOCK_TAI would be one second late from rest of the world until update. But it doesn't affect UTC time on Linux in any way I know.
Isn't this anti-news? I vaguely remember they have stopped introducing leap seconds until further notice because they cause too much trouble with today's computing systems. On my phone now and did not research it, as I say vaguely remember. Now we are 37 seconds off. Nobody of us will have to worry that Christmas is around Easter time. We can leave that problem to future generations much more responsibly than many other problems.
That the notice comes every 6 months is just to meet the letter of the original international treaty.
With the Temporal API will all of the browsers / nodejs etc be able to get the time right when performing operations around that time or will they need to be updated in order to not mess up calculations?
33 comments
[ 3.8 ms ] story [ 52.1 ms ] threadIs it a headache or a non-issue
Meanwhile....
International timekeepers to vote on changing the leap second to a leap hour
https://www.scientificamerican.com/article/international-tim... (https://archive.ph/GnQUj https://news.ycombinator.com/item?id=48842329)
They should live in the same abstraction layer that does leap days and daylight savings: the time zones.
>
> from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37s
This means the atomic clock is behind the solar clock by 37 seconds? I also don’t understand the reference to 2017.
Arguably, the only real-world impact this drift has on normal people is GPS, but GPS already transmits an offset from its own clock so that receivers can correct for that. The GPS clock is different both from UTC and TIA.
Nothing I do requires this level of precision, but certainly there are things that do.
New leap second will get to your system through NTP. Sadly NTP only distributes indicator flag that leap second is going to be introduced, but not the offset itself. But the distributed time itself is already affected by leap second, so NTP client doesn't really need to know.
(In contrast the other time sync mechanisms - GPS and PTP - use time scale unaffected by leap seconds and distribute it as an additional information with UTC offset. And it's left on client to modify received time on its end. Kernel has a parameters in clock_adjtime() for leap seconds.)
So if you have a passive system that has NTP client then it's time will change for new leap second on runtime. Linux treats UTC time as the dominant one, so that's the one saved to RTC device and will survive reboot.
There is CLOCK_TAI that sounds like it should return TAI time, but it is such a second class citizen to the point that nothing on regular Linux desktop and server distros even set the offset and it returns the same time as CLOCK_REALTIME.
There is a file in /etc with list of leap seconds that is part of some package, so you need to update the system to update this file. I don't believe traditional NTP software updates this package dynamically. But not many software uses it. If some init service script parsed and set the kernel UTC offset then your system's CLOCK_TAI would be one second late from rest of the world until update. But it doesn't affect UTC time on Linux in any way I know.
That the notice comes every 6 months is just to meet the letter of the original international treaty.