You seem confused. It doesn't happen every 6 months, it gets announced 6 months in advance – since we know there won't be one this year, it will have only happened twice total in the 10 years prior to December this year.
That's hardly an enormous and constant disruption – turning it in to a multi-minute disruption "every 10 decades" would likely be more concentratedly disruptive, leading to more calls to put it off to avoid the immediate pain, leading to ever-more accumulated error.
Spreading the pain out into a leap second every few years feels like a much better and more sustainable solution. This keeps processes in-use and up-to-date rather than long-forgotten-and-everyone-who-knew-them-is-dead.
It is unnecessary but not because of leap seconds which are the phenomenon of real life, not some abstract invention of astronomers. The unnecessary bugbear is caused by a wrong time system design. We need both the atomic time (which corresponds to number of quartz pulses elapsed since some fixed moment in the past), and the astronomy time (which represents the orientation of the Earth in space).
The decision to mix them up was wrong and is exactly what causing “the unnecessary bugbear”. Do not want the bugbear - fix the cause of the problem.
Anyone involved with bookkeeping and synchronizing should already know to never attempt to handle time conversions using your own program logic updated by hand, because the definition of time is constantly changing and there are already projects like tzdata dedicated to centralizing the handling of it.
There have already been 5 time zone updates this year, 4 changes to the date that Palestine switches daylight savings (one of them with only four days notice!) and Fiji decided to quit using daylight saving time, plus the Leap Second announced on July 9.
But if UTC shifts, it's another story. You assume the UTC (or UNIX) time to be a monotonic counter, and usually it's used this way, for example you compare two timestamps to know what definitively happened before another thing. Surely you don't take into account leap seconds... this is the problem.
Leap seconds wouldn't be that much of an issue if the time is only increased, you have one more second, it's the higher level implementation that has the concept of time to (maybe) deal with it. But they become an issue if they can take behind the UTC clock since it can generate all sort of strange bugs.
It's even a worse solution to make the duration of a second in a day longer or shorted, because you preserve the counter value, but you no longer can rely on the fact of 1 seconds being 1000ms long!
By the way the concept of leap second is nonsense to me. What is the purpose? If the purpose is to keep in sync the time with the rotation of the earth, nobody will ever notice an error of a couple of seconds, or even minutes. It makes more sense to take the current definition of a second, and then wait till the error is noticeable to an human being (let's say an error of 15 minutes, that would take centuries and we will probably far gone from the planet) and adjust it by shifting all the timezone for that amount of time.
The real problem for computing is when UTC is converted to unix epoch time, which is defined as an offset from the past, and by definition has exactly 86400 seconds in a day, every day, so some provision has to be made for those extra (or missing) seconds. And -that- is where the problem happens. But it's not UTC that's mucking around with the definition of time, it's the standard representation of time that's used in modern computing that causes the problems.
That being said, UTC is still probably to blame for most of the problems, because it effectively requires knowledge of more than just a timestamp to understand when something actually happened. And that extra knowledge (the map of when leap seconds have happened before) changes often and irregularly. Epoch time could totally be redefined to include leap seconds, and that would solve lots of problems, but there's no practical way to distribute that updated leap seconds table to every system that would possibly need it...
Does this follow as a question?: Shift the timezones geographically, or in terms of how they all define [true monotonic] to local-time translation?
tzdata is complex, but having waded through it a few times, it seems needlessly so for the desired use cases. There is more editorial comments than data in the files, and they spend a lot of time and effort creating entries for historical time zones so that you can convert times in the year 1942 into territorial time zones that don't even exist any more with perfect accuracy.
Except, even then, it seems like it's not. If you dig into the time routines that use tzdata, you see they must use an unstable conversion process that _may_ converge, but has a simple counter protecting it in the case that it _does not_ converge and in that case it just gives you a best guess time that may still be wrong anyways.
Really.. the problem I have and I suspect is the majority of cases, I have a time in Some/Zone and I want to tell someone in Another/Zone what the time would be on their clock, today, right now. The time our grandfathers would have used during the War in summer is never going to be material to me in this instance or for the majority of use cases.
This isn't meant to be overly critical of tzdata just a recent annoyance I experienced when trying to find a minimal code and cross language solution to the above problem.
> If you dig into the time routines that use tzdata, you see they must use an unstable conversion process that _may_ converge, but has a simple counter protecting it in the case that it _does not_ converge and in that case it just gives you a best guess time that may still be wrong anyways.
What kind of time zone data would be required to make it fail to converge when that time actually did exist?
What does this mean? Can you explain in a little more detail, or link to somewhere I might read about this? I haven't used tzdata myself, but I understand it in broad strokes as a list of time zones, and a list of which offsets apply to which timezones at which given dates. What am I missing?
The problem is that it is not often enough to force you to have a good process in place.
That's pretty awful. We have a lot of systems now which care about duration. Any scheme that makes a time span unpredictable will cause problems. Doing it more often means more problems.
The only improvement is that you hope that the things that care about 1/100th of a second differences are rare enough that disturbing thing many times more often is a good tradeoff. This isn't a good bet especially because at time goes on we build faster and more stable systems that care about tighter and tighter synchronization.
This reality is not unique. Thousands of engineers have walked down this path and asked "why?".
I disagree; I think it would be made worse.
UTC timekeeping in computers depends on a database of leapseconds, which has to be updated. But many systems don't get updated, resulting in drift. If leap-[seconds|minutes] only occur every 2 decades, many systems will ship with no update mechanism, on the principle "Don't worry, the system will be obsolete before twenty years is up". Hah! Famous last words.