Tech Giants Want To Banish the Leap Second To Stop Internet Crashes (cnet.com) 230
Google, Microsoft, Meta and Amazon launched a public effort Monday to scrap the leap second, an occasional extra tick that keeps clocks in sync with the Earth's actual rotation. US and French timekeeping authorities concur. From a report: Since 1972, the world's timekeeping authorities have added a leap second 27 times to the global clock known as the International Atomic Time (TAI). Instead of 23:59:59 changing to 0:0:0 at midnight, an extra 23:59:60 is tucked in. That causes a lot of indigestion for computers, which rely on a network of precise timekeeping servers to schedule events and to record the exact sequence of activities like adding data to a database.
The temporal tweak causes more problems -- like internet outages -- than benefits, they say. And dealing with leap seconds ultimately is futile, the group argues, since the Earth's rotational speed hasn't actually changed much historically. "We are predicting that if we just stick to the TAI without leap second observation, we should be good for at least 2,000 years," research scientist Ahmad Byagowi of Facebook parent company Meta said via email. "Perhaps at that point we might need to consider a correction."
The temporal tweak causes more problems -- like internet outages -- than benefits, they say. And dealing with leap seconds ultimately is futile, the group argues, since the Earth's rotational speed hasn't actually changed much historically. "We are predicting that if we just stick to the TAI without leap second observation, we should be good for at least 2,000 years," research scientist Ahmad Byagowi of Facebook parent company Meta said via email. "Perhaps at that point we might need to consider a correction."
Good idea. The leap second is stupid. (Score:2, Insightful)
There is absolutely no point in synchronizing the clock to the rotation of the Earth to within one second.
Re:Good idea. The leap second is stupid. (Score:5, Insightful)
There's no point in deliberately breaking the system of timekeeping which has been in use for millennia, just because someone can't code properly. Leap seconds have been around for over 50 years, they've had plenty of time to get it right.
If someone doesn't want to deal with leap seconds, there are multiple timescales they can pick from (TAI, GPS...). But leave UTC alone, it is meant to closely track solar time.
Re: Good idea. The leap second is stupid. (Score:3)
Re: (Score:3)
And keeping time is older than 50 years which is what the 'millennia of timekeeping' is referring too.
You've never done code to deal with time (Score:5, Informative)
You've obviously never done any serious astronomy.
Time is far harder to get right in systems than many people assume. You have the time zones, daylight savings problems that everyone knows about. Then you have the event logs from multiple systems where the order of events makes no sense if someone's time stamps drift. And what if your time has drifted and you have timers and events that are supposed to go off during the drift interval. And don't get me started with events that go off during the shift in daylight savings. Or hourly billing when a day has 25 hours in it. And then there are leap seconds. I have to have a table somewhere saying which days they occurred so that my time since epoch matches human billing time. Except that table needs to be updated when a new leap second is added. Will I even be employed at the company the next time there is a leap second so as to create an over the air update. Will the update servers still even be reachable?
Time is far far harder than most people realize. Anything to make it simpler is welcome.
Re: (Score:2)
Time is far far harder than most people realize. Anything to make it simpler is welcome.
Time is hard, because it is hard.
If there would be a way to make it simpler, one already had found one. Don't you think so?
Re:You've never done code to deal with time (Score:5, Insightful)
You're confusing timekeeping with the display of local time.
>don't get me started with events that go off during the shift in daylight savings.
So, don't schedule events based on "wall time." If you do, do it with the understanding that 2:30 AM can occur twice, or not at all.
Re: (Score:3)
It's not just "display" of local time, there are tons of systems out there, criticial infrastructure, that uses local time internally. Remember, Windows used localtime for a very long time as well ("We're Microsoft, we refuse to learn from the mistakes of others!").
The advancement or retardation of time, even UTC time, is a real thing. Clocks drift, and you need to resynchronize. The event system may not be able to handle time that skips forward past an event. I have seen actual real time operating system
Re: (Score:2)
Time is far far harder than most people realize.
Yes, but it is possible to get it right.
Anything to make it simpler is welcome.
Hell, no. Abolishing leap-seconds is not the way.
Human clocks and calendars are screwy (Score:5, Insightful)
While you're not wrong, 99% of the pain can be avoided by using epoch time everywhere but the GUI. Systems generally expect monotically increasing time - it goes up by one second every second. So use that - seconds since 1970 is the standard for *nix.
Generally the only time you care about what day or week or month or hour is the UI, time picker widget. That's the place to have months and days and such mess.
The other place you need calendar stuff is of course financial reporting. Generally that stuff won't go crazy whether you choose 1658809211 or 1658809210 as the cutoff.
Re:Human clocks and calendars are screwy (Score:5, Insightful)
Oh and of course the other thing that makes it easy - use the fucking library.
Someone, perhaps FellGood314, already wrote the hard code for you. It's already done. Don't re-invent it yourself - you'll do it wrong. Just use the stinkin library. :)
Re: Human clocks and calendars are screwy (Score:3)
YES!!!! That is the problem!!
I feel we would solve the problem by switching Unix time to GPS time, or switching Unix time to GPS time + current offset at a set future date.
The leap seconds would be pushed into the domain of timezones and become a presentation problem.
Re:You've never done code to deal with time (Score:5, Interesting)
You've obviously never done any serious astronomy.
Time is far harder to get right in systems than many people assume. You have the time zones, daylight savings problems that everyone knows about. Then you have the event logs from multiple systems where the order of events makes no sense if someone's time stamps drift. And what if your time has drifted and you have timers and events that are supposed to go off during the drift interval. And don't get me started with events that go off during the shift in daylight savings. Or hourly billing when a day has 25 hours in it. And then there are leap seconds. I have to have a table somewhere saying which days they occurred so that my time since epoch matches human billing time. Except that table needs to be updated when a new leap second is added. Will I even be employed at the company the next time there is a leap second so as to create an over the air update. Will the update servers still even be reachable? Time is far far harder than most people realize. Anything to make it simpler is welcome.
All what you said is correct, and it can be even worse : some time calculations in the future (for instance "add 10 years to the current timestamp") simply can't be made, because you can't know that far in advance where leap seconds will be added. Performing such computations produce an "impossible to evaluate" result when using a leap-second aware library.
I learned this the hard way on a project for the European Space Agency.
Re: (Score:3)
Re:You've never done code to deal with time (Score:4, Informative)
Your post suggests to me that accuracy isn't something into which you put too much value.
Re: (Score:3)
Re:You've never done code to deal with time (Score:5, Insightful)
All what you said is correct, and it can be even worse : some time calculations in the future (for instance "add 10 years to the current timestamp") simply can't be made, because you can't know that far in advance where leap seconds will be added. Performing such computations produce an "impossible to evaluate" result when using a leap-second aware library. I learned this the hard way on a project for the European Space Agency.
This is a rationale for why UNIX timestamps use UTC but ignore leap second. If we standardize Google's "leap smear" into timestamps too, then I think the issue will be tamed alright. The clocks found in common PC aren't that accurate anyway and thus standardizing a 1 second drift smeared over 24 hours is not outlandish - it could be already drifting in such rate (or more) every day, and rely on NTP servers for periodical correction.
If there are scientific experiments that care the 0.01 millisecond per second difference introduced by leap smear, they should connect their equipment to a dedicated atomic clock, not relying on computer clocks that are never that accurate. And they can use TAI for their record purpose. Oh, for your space agency need, just use TAI!
Re: (Score:3)
Re: (Score:3)
Whenever I have to build a time handling system, I always use UTC internally with an epoch (usually 2000/01/01 00:00:00). Anything that needs local time or DST is just derived from that.
Which reminds me. Stop changing your DST rules. I'm looking at you, America.
Leap seconds are either ignored or when they come they are treated as one extra long second. It will screw some stuff up if, for example, it needs to count the number of events per second, but my solution is usually to just avoid doing anything at mi
Re: (Score:3)
If you have timers and events that are supposed to go off during a drift interval and they are that important... don't let your time drift. Use the atomic clock radio broadcasts to constantly adjust your time.
I would never writ
Re: You've never done code to deal with time (Score:3)
Yes, you obviously have it all figured out. Perhaps you can do world peace next?
Re: (Score:2)
The article is about getting rid of leap seconds to TAI, not UTC.
Re: (Score:2)
never mind, the article itself is confused
Re: (Score:2)
Re:Good idea. The leap second is stupid. (Score:5, Informative)
Another solution would be to publish the offset between UTC and ephemeris time for the benefit of astronomers or celestial navigators.
The International Earth Rotation and Reference Systems Service does this. Their web site is at https://www.iers.org/IERS/EN/DataProducts/EarthOrientationData/eop.html [iers.org].
Seconded! (Score:5, Interesting)
Trust the tech giants to think they can bend nature to their will!
Seriously, learn to code you lazy bastards....... I work in GNSS where nanosecond time keeping and syncing to UTC is critical and we manage it without problems.
Re: (Score:3)
If you would not do it, you would need to synchronize it roughly every 60 years to one minute.
What is better?
Re: (Score:2)
Re: (Score:2)
Or more likely, every 1000-2000 years to one half-hour, by changing the zone files. This is well-tested, as countries change DST rules and UTC offsets all the time anyway.
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
I don't have mod points at the moment, and didn't mod it as Troll, but it certainly seems like a troll to me. Someone would have to be unusually naive to think that abolishing the leap second is a good thing.
By your standards, there are lots of people who are unusually naive. The summary lists several companies and two government agencies.
Re: (Score:2, Informative)
Actually I think it's a brilliant idea! And while they're at it the tech giants should also define pi to be 3 exactly, and e to be 3 as well (means you can use the same constant as you use for pi, saves code and memory space!). And then make each day 10 hours long, and 100 days a year to keep other time-based calculations more manageable.
Think of how much simpler the world would be if only we followed every brain fart of some IT company.
Re: (Score:3)
Re: (Score:3, Funny)
> If you are seeing it as a 5, then you probably are viewing with an extra bonus assigned to "insightful" or something.
That would be the leap moderation.
Eventual consistency is stupid. (Score:2)
Great. Apparently those companies are being run by programmers that think Eventual Consistency was a great idea and should be applied to everything.
Re: (Score:2)
Perhaps you should google what "Eventual Consistency" actually means.
Because it is indeed a great idea.
Hint: it has nothing to do with SQL constraints regarding "consistency" :P
Re: (Score:2)
Heat death will see to that - eventually.
Re: (Score:2)
There is absolutely no reason to use anything else than (micro)seconds from Epoch at GMT+0 in machine to machine interaction.
And from that you calculate what you need for user interaction.
Computers usually don't need accurate time, but continuity.
Leap smear is a very interesting technique to deal with that leap second madness.
Damn! (Score:5, Funny)
I don't want to lose that extra sleep.
So why are we already off? (Score:2, Interesting)
If we'd be good for 2 millennia, then why have we already drifted 37 seconds in only 40 years? Leap seconds are only "not an issue" for people who don't have to keep track of time over the course of more than a few hours. And frankly they're only a problem for people who convert time back to date-based formats to manipulate it. Hint: most computer systems don't keep time in date-based format, and don't even notice leap seconds when doing arithmetic on times as seconds-since-epoch.
It's a lot like the argumen
Re: (Score:2)
That's half an hour drift over the next 2k years. I think that's probably fine since large parts of the world are in timezones that are already about half an hour off.
Re: (Score:2)
It is much more than half an hour.
And what exactly have time zones to dow with that? Nothing obviously.
Imagine on 23rd of December 2020 at you place the sun rices around 7:30 in the morning. ...
In the year 4020 that would be 6:15
Does not really make sense. Or does it for you?
Re:So why are we already off? (Score:5, Informative)
The rate of leap seconds is not constant. So far we've only had positive leap seconds, but that's a fluke of recent rotation speeds. If we keep the leap seconds, there will be negative leap seconds that cancel out some of the positive leap seconds and reduce the drift.
Re: (Score:3)
That's half an hour drift over the next 2k years
No, because the day is gradually getting longer so the rate of drift is increasing. If you go back 2000 years the offset was about 3 hours (according to NASA [nasa.gov]). Do you really want to be that far off?
Re: (Score:2)
So change the time zones when the drift gets bad enough. This is well tested and happens all the time anyway.
Re: (Score:2)
Yep. Timestamps should be number of seconds since 1970, plus fraction if you want.
A leap second doesn't change that so databases won't break.
The only thing that changes is the code to convert a timestamp to human-readable format and so what if it's off by one second until the next patch?
Re:So why are we already off? (Score:5, Informative)
That's what POSIX says, but it's not what it does. POSIX ignores leap seconds.
Re: (Score:2)
POSIX ignores leap seconds.
You got a source on that?
Re:So why are we already off? (Score:5, Informative)
POSIX ignores leap seconds.
You got a source on that?
The POSIX documentation is Standard for Information Technology–Portable Operating System Interface (POSIX®) Base Specifications, Issue 7. IEEE Std 1003.1, 2016 Edition (incorporates IEEE Std 1003.1-2008, IEEE Std 1003.1-2008/Cor 1-2013, and IEEE Std 1003.1-2008/Cor 2-2016), pages 1–3957, Sep. 2016. doi: 10.1109/IEEESTD.2016.7582338
POSIX section 4.16 defines "seconds since the epoch". It contains these two paragraphs:
I think it is clear from that last sentence that "seconds since the epoch" ignores leap seconds.
I advocate not using "seconds since the epoch" since it is so poorly defined. For details, see my paper on the subject: https://www.systemeyescomputerstore.com/leap_seconds/avoid_time_t.pdf [systemeyes...rstore.com].
Re: (Score:3)
Re: (Score:2)
He's correct. Look up the terms TAI, UT1 and UTC and read up on their definitions and the differences between them. For most people they don't really matter as long as everything uses the same one of them consistently, and almost all computers use UTC for timekeeping, but for the people who have to deal with eg. atomic clocks they're a big deal and an almighty headache if you want things to be right, not just consistent.
Re: (Score:2)
The clock was many seconds out of sync when the leap second was introduced - they fixed that by having, I think, predetermined leap seconds every year until they caught up. So, that's more like 37 seconds over maybe 60 years.
And it sounds like their argument is that we wouldn't really need to adjust things until it got to be something like an hour out of sync with the Sun. After all, we randomly jump our time back and forth by an hour because we feel like it (DST rubbish), and the time of sunrise and sunset
Re: (Score:2)
Time being off by an hour would mean for a sailor using stars for navigation to be off by roughly 360/24 -> 15 degrees, which is up to 900 nautical miles (at the equator it is 900 nautical miles), which is roughly 1040 land miles.
People who think time is not important: are idiots.
Re: So why are we already off? (Score:2)
Re: (Score:2)
As a former developer of personnel scheduling software, I disagree verily.
Best Solution (Score:4, Insightful)
I have a better idea (Score:5, Insightful)
How about we attach a giant rocket engine to the Earth at the equator, and every day at a certain time, when it points rearward, fire it for a few minutes to speed up the Earth's rotation around the Sun until it matches exactly 365 days.
Or...
Get less lazy programmers and tell them to code code that handles seconds values over 59 without barfing.
Re: (Score:2)
It is seconds values less than one that are the real problem.
Re: (Score:2)
Re: (Score:2)
This can be solved with more rockets. :)
Re: (Score:3)
This is more about the rotational speed of earth rather than orbital period. A day is not exactly 24 hours.
Both rotational speed of earth and orbital period are part of the equation and impact the duration of a day.
Earth rotation period is almost exactly 23 hours and 56 minutes, ~23h56m04s. Yet, we have a 24 hours day due to the orbital period around the Sun.
here are some numbers with bc:
(86400-(86400/365.25))/60/60
23.9342915811
0.9342915811/60*3600
56.0574946800
0.0574946800*60
3.4496808000
In short, the daily noon alignment with the Sun arrives later because the Earth is also moving around the sun so the Earth need
A Software Problem (Score:4, Insightful)
Re: (Score:2)
Option 2: rewrite the entire calendar
Then sync system clock to IAT (Score:5, Insightful)
The Atomic clock (IAT) is what is used for people into timekeeping, and it does not leap. The leap second is what is added to sync the Universal Time, and it is an interesting feature to civilian time have synced within a second.to astronomical events. It is also maintained by astronomers who know what they are doing.
Tech giants are in charge of computer programming and ought to find a technical solution to program computer timekeeping in agreement with the level of what astronomers figured. Now they are saying the new Y2K bug is so difficult that we better start counting back at year 0 to avoid problems.
One future-proof solution could be to sync computer clocks to IAT instead of UTC and add leap seconds to timezone-data. It's easy in Unix systems because unix system clock is UTC so the difference is a known 32 seconds, while Windows would need to change from local time system clock to IAT/UTC and that could be what irates Microsoft.
Re: (Score:3)
Windows hasn't crashed because of leap-second bugs, as far as I know. The Linux kernel has. The POSIX and NTP handling of leap seconds is fatally broken and unfixable without changing the standards. Windows should have an easier time of it.
Re: (Score:3)
...There is no way for a Linux application to opt in to correct leap second handling. ...
But there is. The Linux kernel has a function adjtimex. Call it with mode 0 and it will return the time and a flag, TIME_OOP, if there is a leap second in progress. Convert the time to a tm structure using gmtime and add one second (changing 59 to 60) if TIME_OOP is set. You now have the time represented in a tm structure that is correct even during a leap second.
And in other news... (Score:2, Funny)
...tech giants call to abolish gravity, saying "It makes our data centers heavier."
Re: (Score:2)
Re: (Score:2)
Actually there is. Depending what you actually want to name a "law of nature".
Or do you think it is an accident^H^H^H^H^H^H^H coincidence that a circle has 360 degrees and the year is 365 days long?
Re: (Score:3)
Actually there is. Depending what you actually want to name a "law of nature". Or do you think it is an accident^H^H^H^H^H^H^H coincidence that a circle has 360 degrees and the year is 365 days long?
The circle has 360 degrees because the Babylonians liked numbers with lots of factors. The factors of 360 are 1 (obviously), 2, 3, 4, 5, 6, 8, 9, 10, 12, 15, 18, 20, 24, 30, 36, 40, 45, 60, 72, 90, 120, 180, and 360 (obviously). The year is about 365 days long because the Earth turns on its axis about 365 times for each time it revolves around the Sun. There is no causal connection between the two numbers.
Future peoples problem (Score:2)
2000 years in the future... (Score:2)
"We were such fools!"
How about just changing Unix time (Score:3)
Their presence in Unix time causes 99% of the problems ... are Unix nerds too cowardly to change it on their own because the POSIX constitution is inviolable so they need UTC to change?
Kinda funny that the world has to change not just to suit them, not just to make their code work ... but to make their fucking standards work. Get your shit together nerds.
Re: (Score:2)
Unix time is a perfectly good way to store time. Seconds since 1970, simple to understand. The decision to not include the leap second in Unix time was a reasonable one - you can choose to include that complexity when you are displaying the time thousands of times a day, or once every few years when you adjust the clock.
Of course, there is always a corner case caused by there being a whole second every few years that doesn't have a Unix timestamp. But coping with that complexity in the places where it matte
Re: (Score:2)
They do include leap seconds in Unix time, as repeated seconds. It could have just been SI seconds since the epoch, but instead it's UTC seconds which has caused most of the big crashes.
Re: (Score:2)
That's what I'd call 'not including leap seconds' - Unix time ignores their existence. And for almost all uses of UNIX time, the programmer can ignore their existence, as well. That is a good thing - make UNIX time the actual number of seconds since the epoch, and every programmer would have to deal with leap seconds every time they presented the user with a time. No thanks!
If you are one of the few that need to take them into account - like, having the occasional interval calculation be inaccurate by a sec
Re: (Score:2)
Many of the crashes have been when scripts crash when trying to parse x:59:60 (or even x:29:60 in a few timezones!) - that would happen whether the underlying structure tracks leap seconds or not.
Linux time never returns :60. It returns :59 twice or effectively stops the clock for a second, or (the less-insane Google way) makes seconds longer for 24 hours. All those options are somewhat crazy, but since NTP is broken, the options are limited.
Re: (Score:2)
So what would you call simply SI seconds since the epoch? Double plus not including leap seconds?
Re: (Score:2)
a) Seconds since 1970, simple to understand.
Correct.
b) The decision to not include the leap second in Unix time was a reasonable one
Wrong. Leap seconds are included. Otherwise a) would not work. (* facepalm *)
It is already ignored by GPS (Score:2)
The GPS satellites already ignore the leap seconds.
https://en.racelogic.support/V... [en.racelogic.support]
Why? Receivers require very precise clock analysis to triangulate locations on Earth. They let go of being on perfect sync wrt. UTC to make sure no unintended bugs were introduced.
Could this be handled? Sure. Can they add additional features and tests to make sure satellites were exact wrt. UTC? Sure. Would it still fail in unpredictable ways? Sure, have you never done any programming?
Re: It is already ignored by GPS (Score:2)
Triangulate? (Score:2)
Triangulate?
Good god man! Do you think a GPS receiver measures angles to calculate its position?
Look up Trilateration. The difference is an important one.
https://www.gps.gov/multimedia... [gps.gov]
An even better idea: (Score:2)
Create and use a time library that doesn't fsck whatever program is using it.
It should be a solved problem by now. Input a number of seconds from some type of epoch, get an output date in string format. Input date string (potentially with how it's supposed to have been formatted), get associated timer.
And while they're at it - find a way past all the politics and get a standard way of writing dates.
Re: (Score:2)
I see lots of comments very similar to this one, and it's clear to me that not one of the commenters has ever looked at the source code for the UNIX `date` and `time` commands.
Date and time are notoriously difficult to get correct in software because actual human beings need to keep time in a universe whose macroscopic physical systems are not evenly divisible into seconds or even take the same amount of time repeatedly.
Re: (Score:2)
Create and use a time library that doesn't fsck whatever program is using it.
It should be a solved problem by now. Input a number of seconds from some type of epoch, get an output date in string format. Input date string (potentially with how it's supposed to have been formatted), get associated timer.
And while they're at it - find a way past all the politics and get a standard way of writing dates.
I have written such a time library. It is available as free (libre) software on github at https://github.com/ShowControl/libtime [github.com]. The documentation is at https://www.systemeyescomputerstore.com/leap_seconds/avoid_time_t.pdf [systemeyes...rstore.com]. See also my diatribe about leap seconds at https://www.systemeyescomputerstore.com/leap_seconds/index.html [systemeyes...rstore.com].
Re: (Score:2)
Falsehoods programmers believe about time [github.com]
What what if? (Score:4, Funny)
Re: (Score:3)
You will for sure anyway.
No they have not (Score:2)
TAI is syncronized with a set of atomic clocks. There are no leap seconds. UTC is TAI plus leap seconds. If you don't like leap seconds, use TAI, that's why it's there.
who's in charge here anyway (Score:2)
roughly a minute a century
over 2,000 years, about 20 minutes
would throw lots of shit all over the place
that's why we have a gold standard and NTP
tech giants might own the world but so far don't control it
or do they ???
tech solutions (Score:2)
A typical tech solution. "Let's plug a FIXME comment into there and worry about it later"
No, morons. There is a working solution right now that avoids the problem that you're trying to shift into the future. It's just annoying for you to deal with it, so you'd rather create a larger problem sometime later than a small problem now.
A negative leap second could cause more chaos (Score:3)
and one seems more likely than ever before. The UT1-UTC graph [wikipedia.org] is looking like crossing into positive territory by the end of the year. If it makes it past about +0.7s they'll have to cancel a second for the first time ever, no doubt causing massive software failures. UTC will have to tick from 23:59:58 to 00:00:00, skipping over 23:59:59, on either 30 June or 31 December.
But my view is that the current system should be retained. The long-term average makes it look like leap seconds will become increasingly common. Computers can keep a continuous time scale like TAI internally and convert to and from UTC as necessary with a table of leap seconds.
The statement that "we are predicting that if we just stick to the TAI without leap second observation, we should be good for at least 2,000 years" seems bogus. NASA says [nasa.gov] that the offset as of 2,000 years ago was around 3 hours.
Next step... (Score:2)
Here's the deal... (Score:3)
... they can scrap the leap second iff they pay to fix the Earth's rotation first.
Apple Watch (Score:2)
At that point you have to ask: 50ms compared to what exactly? For example, GMT and UTC can be 900ms apart, so it can only be within 50ms from one of them.
I have looked at Appleâ(TM)s APIs and there is nothing obvious that would report leap seconds. Their APIs assume years, leap years with 29th of February added, time zones and DST, but assume 24x60x60 se
Wrong solution (Score:2)
Most people are just fine with astronomical time. Itâ(TM)s preci
Re:Y2K (Score:5, Informative)
No, Y2K was not a bunch of ado about nothing. There was a lot of something, but because of the attention, it was fixed in advance, so nothing of significance happened. The problem with leap seconds is that they are rare, unpredictable (more than a few months in advance), and nobody wants to spend time or money testing for and fixing issues.
Leap seconds do not happen on a regular schedule - they're inserted as needed, which happens to be rather irregular. Some (notably Google) do the leap-second "smear", but that has other issues.
Re:Y2K (Score:5, Informative)
Or, if you're going to cater to lazy admins who don't keep their systems up-to-date, have the NTP masters make every second on leap-second-day 1/86400th of a second longer.
Google apparently pioneered a system that did precisely that. It's called the "Leap smear".
https://developers.google.com/... [google.com]
Re: (Score:2)
The Linux kernel has crashed due to leap second handling. More than once, in separate bugs. And you really don't know how leap seconds work, they ARE added at random whimsical times, because the Earth rotation speed changes at random whimsical times.