It's not just a headsche for Meta's programmers. Anyone involved with bookkeeping and synchronizing has an unnecessary bugbear to deal with. Every six months is simply too often. If it was switched to an adjustment made every 2-10 decades with at least a decade to update the file then the problem would be greatly lessened.
> Every six months is simply too often. If it was switched to an adjustment made every 2-10 decades with at least a decade to update the file then the problem would be greatly lessened.
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.
> Anyone involved with bookkeeping and synchronizing has an unnecessary bugbear to deal with.
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.
Palestine switched off Daylight Saving Time this year with only 4 days notice.
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.
That is a different problem. You usually work with timestamps and then convert the time to local time only when displaying it or doing calculations that depend on the particular timezone. So it's less of a problem, since at lower levels you don't have the concept of timezone (you may never have it, for example on embedded devices).
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.
Actually, UTC -is- continuous. Even with leap seconds. At no point does UTC go backwards, at no point does a second happen twice, and at no point does a second change in length -- your 'extra' second happens as 23:59:60; when there's a negative leap second, the last second of the day is 23:59:58. UTC is not expressed or defined as an offset from some time in the past.
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...
That would most be a local problem and would not continue to exist for a long period of time.
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.
Extra historical zones and comments don't add any real complexity, do they?
> 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?
> 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 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?
See the code for __mktime_internal in glibc, specifically the case for which it returns EOVERFLOW; but in general, the whole file has many comments worth reading.
> So another option is to adjust to 1/100 second every few months
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.
Because tzdata is based off of political boundaries and decisions. If I'm making a dataset that needs continuous timestamps for multiple decades then UTC is effectively off the table because of how under-specified and poorly implemented leap seconds are in various software. So what's left is TAI and GPS, fine enough but now users see the timestamped data as being several seconds off. So we use a translation layer but some HMIs don't allow that so it's best to just not do it at all.
This reality is not unique. Thousands of engineers have walked down this path and asked "why?".
It isn't every six months, the Earth doesn't rotate that regularly. They are introduced "at most" every 6 months, but usually far less. There have been 27 leap seconds since 1972, so less than one a year.
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.
