It’s time to leave the leap second in the past
engineering.fb.com
engineering.fb.com
This periodic adjustment mainly benefits scientists and astronomers as it allows them to observe celestial bodies using UTC for most purposes
Astronomy algorithms usually work in Barycentric Dynamic Time, or Terrestrial Time, or UT1. In reality the whole invention of UTC is so that people don't have to deal with those systems on a daily basis.
The process most astronomy programs go through is to get the UTC from the user, convert the Gregorian date to a Julian day number to get rid of the Gregorian Calendar altogether. Then look up the number of leap seconds, add those to the JD to get International Atomic Time, then add 32.184 seconds to get Terrestrial Time. If Barycentric Dynamic Time is needed, you must first compute the velocity of the Earth relative to the solar system barycenter (which itself requires TDB), then compute the relativistic effects of that motion on Terrestrial Time. If you need UT1, these can only be obtained by observation from the International Earth Rotation Service, and required daily updates, and interpolation of values in between observations.
So, as you can see, leap seconds do nothing to make an astronomer's life easier. In fact, we jump through a lot of hoops to make the average person's life easier. It sounds like Meta wants to change the definition of time for everyone just to make their programming a little easier. I find the very premise just out right ridiculous.
It's true that your average person will not be affected by the Sun setting a few seconds earlier. But eventually it will build up enough error that it eventually has to be addressed, and Meta is just trying to make their problem someone else's problem.
> these days UTC is equally bad for both digital applications and scientists, who often choose TAI or UT1 instead.
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?".
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 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.
Does this follow as a question?: Shift the timezones geographically, or in terms of how they all define [true monotonic] to local-time translation?
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...
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.
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?
> 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?
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.
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.
Meta (and everyone else behind this proposal) are arguing that leap seconds are more trouble than they're worth. Just as you are in the specific case of astronomy.
> It sounds like Meta wants to change the definition of time for everyone just to make their programming a little easier. I find the very premise just out right ridiculous. ... Meta is just trying to make their problem someone else's problem.
Meta's argument is: we should get rid of leap seconds because even though they're helpful for astronomers, they're bad for everyone else.
Your counterpoint was: Actually leap seconds are _also_ bad for astronomers.
Which implies then that Meta is even more right to suggest that we get rid of leap seconds, because it seems like they help nobody.
Like a straw man would be Meta saying "astronomers think that leap seconds are helpful but in fact they're not useful for anything!"
Here, if anything, Meta is attempting to steel man leap seconds a bit by saying "look, sure, leap seconds are at least useful for some things, like astronomy, but they're still not worth it overall". And GP is claiming that it's not a very good steel man because even astronomers don't like leap seconds.
The GP's point is that astronomers find leap seconds annoying too, so Meta's argument is based on a faulty premise.
Unless it is "programmers' employment assurance".
If the actual leap seconds do not benefit astronomers, and do not benefit anyone else, they are purely a tax on us all.
Abandon leap seconds in UTC, and literally everybody is better off. Even astronomers, who would go from managing 3 time systems to just two.
I hear the argument that we have to deal with this eventually to keep time in track with mean solar time, but the adjustments are so small that I don’t see any real impact on regular people.
May as well dispense with the calendar entirely and just measure time in powers of ten.
An day is about 80 kiloseconds, and a year about 30 megaseconds.
Maybe many gigaseconds into the future our descendants will learn about old Earth time keeping in school, along with Roman numerals and the imperial system.
That just means that Meta is even more correct.
So you would be arguing that meta was being to charitable to the opposing side, and is even more correct than they originally appeared.
The decision to ignore leap seconds reminds of the decision by Russian and some other orthodox churches to ignore changes introduced by Gregorian calendar. The decision saved them some internal political problems, like the need to decide which saints will have their celebrations missing, but now the Orthodox Christmas is moving to summer with the speed of about 1 day per 100 years. Eventually somebody will have to deal with this, but not now - there’s a lot of time - same thinking.
Meanwhile, if you leave in a Gregorian country you can have your Christmas tree for free on Orthodox December 12th…
#borealocentrism
Guilty as charged. Thinking of that - there could be no more Russian winter as we used to it at all, even in the Northern hemisphere. My friends are now growing apricots in the Russian temperate zone. Apricots! - in the place there the “Baptismal Frosts” (to happen each year just before Christmas) used to kill all such fancy vegetation.
#climateasitwasbeforechangecentrism
The Islamic calendar drifts by about 10 days a year, and Muslims seems to be able to cope fine with their holidays not consistently being in the same season.
> If the change is implemented, “the old meaning of time will become ambiguous,” warns Steve Allen, an astronomer at the Lick Observatory in Santa Cruz, California.
This does seem like a problem that is solvable.
In 2015 the ITU (mentioned in that 2003 story as studying the problem) announced:
> The ITU World Radiocommunication Conference (WRC-15), currently in session in Geneva from 2 to 27 November, has decided that further studies are required on the impact and application of a future reference time-scale, including the modification of coordinated universal time (UTC) and suppressing the so-called “leap second”
https://www.itu.int/net/pressoffice/press_releases/2015/53.a...
In 2012 they also decided to defer:
> ITU Press Release of 19 January 2012 - ‘ITU Radiocommunication Assembly defers decision to eliminate the leap second’
It's not a quote, but the article also has Allen saying that "it could cost between US$10,000 and US$100,000 for each telescope to correct the problem, and that corrections will be tricky to implement."
It also has another astronomer claiming problems: "But separating time from rotation would mean that telescopes would no longer function properly, according to Patrick Wallace, an astronomer at the Rutherford Appleton Laboratory in Oxford, UK. Most telescopes with a viewfinder wouldn't be immediately affected, but instruments that track satellites and other moving objects could feel the effects within a few years, Wallace warns."
It sounds like FB/Meta is correct in saying that Astronomers did object. I'd suggest (like Mata does) those objections are not especially important considering the trade-offs though.
I'm with Allen. It's fine to drop leap-seconds; but then it's not UTC any more, it's a new time scale, and it needs a new name.
We've made this mistake before: in fact GMT has been redefined many times, and as a result the time interval between two GMT timestamps depends on which versions of GMT the two timestamps use, and so on the dates of the timestamps.
Allen has an instructive page on time scales here: https://www.ucolick.org/~sla/leapsecs/timescales.html
But, for the latter problem, a better solution would probably be to have a service similar to NTP, that gives the current Greenwhich sidereal time, rather than UTC. Then it could be corrected more often than the current leap seconds. That doesn't solve the problem for existing telescope systems though.
> Meta is just trying to make their problem someone else's problem.
It sounds like you agree that leap seconds themselves are a problem for people besides Meta?
I agree with gmiller here: https://news.ycombinator.com/item?id=32229049 that the whole thing smells like Facebook's engineers wanting to save themselves some work, at the cost of generating more problems for the future.
This kind of garbage attitude is why we have climate change, covid-19 and so many other things wrong with the world. Befitting that this one came from facebook.
It's not Facebook. Even the examples of the post include non-Meta. It's not "some work". It's how we conceptualize time moving linearly, and that logic encoded on software.
People just want a reason to dig on Meta.
It sounds like you agree that leap seconds themselves are a problem for people besides Meta?
However, in the past 50 years, we've only had 27. So at the current rate, probably more like 6667 years to be off by an hour.
Of course, if the earth's rotation changed speed by so much that 2 leap seconds per year wasn't enough, we'd find a way to cram more in. In fact, in that case, the case for leap seconds would probably get stronger.
How long has the 9-5 even existed? Less than 200 years? At no point in 6667 years would anyone notice any consequences of the drift, culture and work schedules change so much faster than that.
The Julian calendar being off with regards to leap years wasn't a problem… until it was. And then someone had to fix it:
I think your comment is a precursor to what would happen if we tried to get a one-off event right…
My understanding was that leap seconds are only ever added. It’s not like this averages out over time. The problem is that because they are only added the effect is cumulative and eventually some future generation will be eating lunch at 00:00:00.
So no real change to the status quo?
Computers are another story though, perhaps in the past "a typical computer clock" could be on the order of seconds off and be fine. When computers start to control things like wireless networks (cellular is a problem today, time accuracy is a design factor in evolving Wifi as well), those seconds turn into microseconds very, very quickly. The whole point of the article is to reduce unnecessary complexity in the existing complex time synchronization systems.
If you're running large infrastructure, the next leap second is going to cause an outage somewhere in your org, and the cost may be very large.
Can we switch to leap minutes instead? In the worst case it would mean to adjust the time once in 30 years, which means that astronomers and software engineers would have to deal with this problem no more than 3 times in a century. Fair enough IMHO.
And how often does time code mess that up? We have leap years regularly every ~4 years, and how does time code mess that up?
And you think that a one-off event is going to go smoothly?
It's less than a minute in a life span. Just skip summer time once every millenium something.
I’m not saying that abandoning leap seconds is a good idea, just that abandoning them wouldn’t consign future generations to whacky schedules.
But you seem to be implying that you do not want to get rid of them, which surprised me. After you made your case for how they actually make things harder for astronomers, I thought you'd be in favor of eliminating them.
You seem to be against eliminating them, but are not saying so clearly, or explaining why. Unless I am misunderstanding. Can you explain why you object to getting rid of leap seconds? Is it because of value to astronomy, or because of value in other domains despite the inconvenience to astronomy? Other? Or do I misunderstand?
I also misread their argument until this point. But there is no reading that makes sense except that Meta’s programming problems protect everyone else from dealing with the drifting time.
I think this is right. There will still be calculations for sunrise and sunset which will have to make the calculations.
The shifting will be invisible, and someone can update the formula once a century.
Personally, I think we should return to the Julian calendar. Leap years are too complicated otherwise, not worth the trouble.
"Everyone should change how they do things because it isn't valuable to us personally"
Nah
> Barycentric Dynamical Time (TDB, from the French Temps Dynamique Barycentrique)
Your point is that astronomical systems don’t use IAT directly but instead start with UTC and convert across various other systems? Could be, but then the purpose of UTC syncing was lost somewhere. Any idea why?
(1) https://www.nist.gov/pml/time-and-frequency-division/leap-se...
> While the leap second might have been an acceptable solution in 1972, when it made both the scientific community and the telecom industry happy, these days UTC is equally bad for both digital applications and scientists, who often choose TAI or UT1 instead.
Business as usual
The GPS CNAV messages (on L2C and L5) have support for the Earth orientation parameters, but GPS isn't broadcast those messages yet. Maybe we'll get them with the OCX deployment. BeiDou 3 is transmitting the Earth orientation parameters now. So this one tiny bit of your headache will get easier in the near future as receivers start to forward these data along.
It's also incredibly common attitude amongst software engineers and software engineering organizations. "Simplify" often means push complexity off of us and onto others.
> ...Meta is just trying to make their problem someone else's problem.
Exactly right.
Their report says:
Some members of the astronomical community have expressed great concern over any change to the current system. These concerns are based on the use of existing software that takes advantage of the current definition and uses UTC as a substitute for UT1. Their requirements for precision are such that the current 0.9-second tolerance is adequate, and their software has been designed accordingly. Should the definition of UTC be modified in any way that would permit this tolerance to be exceeded, they anticipate it would create a substantial cost to make non-trivial changes in existing software. Some members of the astrodynamic community have voiced similar concerns regarding legacy software used in the determination of orbital parameters of artificial satellites that again utilizes UTC as a substitute for UT1.[1]
So I'd suggest the FB summary of their objections is pretty much correct.
Reading the report completely, it seems the IAU wants to create a new time standard (not UTC) that drops the leap second and keep UTC as it is:
It was suggested that a means of transitioning to a uniform time scale could be accomplished by the creation of another time scale that might be called Temps International (TI) to clearly distinguish it from Universal Time.
[1] https://www.atnf.csiro.au/iau-comm31/pdf/ContDoc-010_IAU_060...
I was partially motivated to write about leapseconds because I'd spent much of the day trying to construct leapsecond tests for my telescope pointing code. You're absolutely right, leapseconds don't help astronomers.
Casual astronomy will do a one star alignment, so in effect they'll point at a star find out where it is and from it effectively compute the UT1 UTC offset (along with correcting other sources of pointing error). This applies no equally for electronic or manual pointing.
More serious astronomy with use the IERS Bulletin A data. https://datacenter.iers.org/productMetadata.php?id=6 Without it you UTC would only get you within 0.9 seconds (and you won't know the other polar motion terms), so you might as well just platesolve. If you do have the IERS data you have to then back out leap seconds.
You note you need constantly updated tables to do that, but it's worse than that: All over the place systems are getting their UTC replaced with leap-smeared UTC without the operators knowledge. You can't just back out leapsmear especially if you don't know you have it.
I'm sure leapseconds sounded like a good idea on paper and when only a small number of especially exotic systems needed to deal with them. But the pervasive computerization since the 1960s has increased the cost of leapseconds by many orders of magnitude.
> But eventually it will build up enough error that it eventually has to be addressed
Yes, in 4000 years or so people can adopt new timezones that are shifted over by an hour. We already have comprehensive support for timezones, and support for them changing (as they're fairly vulnerable to political whim), computers handle them reasonable well-- and importantly they're primarily a presentation element so they don't mess up precise timekeeping. Maybe in 4000 years no one will even care-- perhaps everyone will have finally switched to SWATCH INTERNET TIME. But regardless, a timezone addition/change every few thousand years is a much better situation than we have with leapseconds.
This named after bary Centre?
Yet, not nearly so bad as Google's approach: no leap, but a 24-hour smear, during which 24 hours they are out of sync with literally everybody else in the world.
It seems like if the ITU decides to keep the leap second (a bad idea, in my opinion), the large infrastructure providers will just use the same standard smear for their clocks.
Few others will do anything so idiotic.
The Facebook smear is asymmetrical so it starts off 1 second off just after the leap second, and subsequently corrects itself.
[ The reason Google and Amazon use a linear smear is because NTP clients try to measure the rate difference between their local clock and the reference clocks; if that is different every time the NTP client queries its servers, it will have trouble locking on and accurately matching the smear curve. You can mitigate this somewhat by fixing a higher NTP query frequency, but that’s a heavy-handed fix for an engineering mistake. ]
Ordering of events, on what scale are we talking here? If it’s just within a transactional database there are multitude of ways to do it. Even distributed dbs have such features without relying on perfect time. If you are looking at a spanner style db you need a lot more guarantees than “I just used the time my cloud provider assigned to my vm”, plus being in sync only matters within your own cluster?
Eliminate UTC leap seconds, and the overwhelmingly worse smear problem vanishes too.
> The AWS Management Console and backend systems will NOT implement the leap second. Instead, we will spread the one extra second over a 24-hour period surrounding the leap second by making each second slightly longer.
https://aws.amazon.com/blogs/aws/look-before-you-leap-the-co...
AWS and Google would like to think the internet is just them, but they are a tiny little bit of it.
Systems that use atomic clocks might have been able to do 10,000 transactions per second will suddenly only be able to do 2 transactions per second if they contain a node that doesn't use the same smearing.
Yes I could come up with an algorithm where this is a problem, but in most cases I’d favor a solution that doesn’t depend on separate systems having clocks perfectly in sync.
If you don’t, then you already have to deal with standard drift with ntp anyways so Googles time smear is the least of your problems
https://dl.acm.org/doi/10.1145/112600.112601
Google spanner uses stuff like this with a clock called TrueTime. I don’t know how leap seconds / smearing is handled in that system.
From a purely academic perspective, it means from noon preceding a leap second to noon after the leap second there's a difference between UTC and what google (and anyone else who does smears) reports as the time. If you really hated yourself and were trying to use timestamps from conflicting sources to order transactions in a database, for example, this could mess up the order of your transactions which could have all sorts of fun consequences.
I think smearing can help reduce outages. The article mentions that reddit and Cloudlare had outages caused by leap seconds when they weren't smearing. I think it's a tradeoff between being standard and avoiding outages.
Disclosure, I work at Google.
> Official time would slowly move out of sync with Earth’s rotation, but — given that it would take thousands of years to accumulate a difference that is greater than the kinds of shifts already caused by changing the clocks backwards and forwards for daylight savings time
I think this argument: that we're syncing to atomic clocks and keeping in sync with the sun isn't so important should have been included in the post. I stand by my earlier comment that it felt like a hack, but aligning with SI unit of time + atomic clocks is, I think, far superior.
Their name, Meta and Zuck’s name is too sullied for good faith discussions
> Britain’s argument is largely based on the desire to keep a link between official time and Earth’s rotation, says Peter Whibberley, a metrologist at the National Physical Laboratory in Teddington, UK.
just seems silly. Bit more from Whibberley here [1]:
> There's no agreement internationally. Some countries favour ending leap second because they do cause problems. Some software in particular has great difficulty handling leap seconds. The simplest solution is simply to end them.
> But other countries say it's important to maintain the traditional link between timekeeping and the Earth's rotation and arguing we should keep leap seconds until at least we understand much better the long term consequences of ending them.
> Well, I'm part of the UK's delegation at this grand meeting that would discuss the issue in November of this year. So, it's my job to argue the UK's position but from a personal point of view, I don't have any stronger sympathies one way or the other. They're both very good arguments and the problem is, no compromise position. You had to keep leap seconds or you end them. Whatever happens, it's going to be very interesting.
> The UK government has considered the issue and it's theory is we should maintain this traditional link between our timekeeping and the Earth's rotation.
Some random googling turns up a document [2] which says:
> The UK has previously consulted official bodies and agencies with an interest in precision timekeeping. None of these authorities reported significant problems arising from leap seconds, while some scientific institutions reported strong support among their memberships for retaining leap seconds.
With a reference to the article 'A British perspective of the future of Coordinated Universal Time' [3], which is longer, but doesn't really contain any more substantive points in favour of leap seconds. Looking for that also led me to a more detailed presentation on the subject [4]. Hmm.
[1] https://www.thenakedscientists.com/articles/interviews/what-...
[2] https://sciencewise.org.uk/wp-content/uploads/2021/03/DR-5.p...
[3] p. 51 of https://www.itu.int/bibar/ITUJournal/DocLibrary/ITU011-2013-...
[4] https://www.itu.int/dms_pub/itu-r/oth/0a/0e/R0A0E0000960014P...
UTC has the leap second cause it's not "real time" and so now we're just gonna never sync up UTC to real time at all? How is that the solution? Either we deal with leap seconds or we need to implement something that can't go backwards and properly models time. Leap seconds seem much simpler...
In the end we didn't get rid of SQL cause of SQL Injection. We fixed the frameworks and promoted the solutions. We may simply need to make a push for languages and etc to just properly support time and promote how to do things correctly. It honestly seems easier.
There simply is no definition of solar time that can obey this constraint long term, because the rotation of the earth varies, and varies over time in ways we have a limited ability to predict. This is the entire crux of the problem.
But they have their own solution we need pay exactly zero attention to. Leap seconds in UTC are just as big a nuisance for them as for everyone else. They have TAI, sidereal time, and this dumb bastard UTC with its own hacked up thing that doesn't match their precise alternative.
Meanwhile, making sure everyone agrees as to the kind of time they're talking about it hard enough.
If they stop announcing leap seconds, everything correctly equipped for leap seconds will still work, and everything else that gets it wrong every time will also work.
And those of us who have to make the stuff that works right adapt to all the crap that doesn't and can't be fixed can do other things, instead.
We have IAT if you want a monotonic measure of time: https://en.wikipedia.org/wiki/International_Atomic_Time
Use the right tool for the right job. UTC is what it is. Trying to redefine it is as stupid as redefining a foot so 3 feet are a meter exactly.
Fixing UTC by simply not declaring any new leap seconds eliminates all problems. What used to break on a semi-regular basis stops breaking. Nobody suffers. Nobody pays. No problems surface.
Leap seconds have not sit well with me ever since I learned about them. Messing with the number of seconds in a certain minute a few times a year just seemed ... unclean.
So if fellow commenters are right, that without leap seconds it would take 6667 years for the time to drift just one hour, then leap seconds are absolutely more trouble than their worth, and we should drop it this instant and try to come up with a solution for that leap hour in the next six milleniums.
This is like people saying that we shouldn't have daylight savings so we should redefine GMT to not have DST. That is not only stupid but breaks all use cases where you care about historical DST.
This is why we have UTC, it's GMT - DST. People in 1960 could figure this out. Are we so incompetent that our grandfathers were better programmers than us?
Crap programmers' grandparents were no better than they are. We live with it all. All their code doesn't work right and won't be fixed.
But, stop breaking it with leap seconds, and it will stay not broken.
TAI > UTC > UT1
That said, the hard work to build out a compromise has already been done, so whatever, let's just keep it until political or speed-of-light issues make it awkward to distribute information about leap seconds, at which point dropping them will be an easy and natural solution.
Who's definition... the whole relativeness of time means this is a problem.
Yea, I agree that we should have a unit of time defined for things near sea level and not moving very fast. But even that becomes problematic over 'long' periods of time as the earth is slowing down and will skew from what humans experience, of which has been the basis of how we define time until recently.
Even then we're still leaving out the problems of things in space and on other planets.
At the end of the day we're attempting to define time as something exact for all observers, and when you attempt to give an exact definition to something that is not exact problems are going to occur.
If you define time in terms of days and years, I.e in term of revolutions of the earth around the sun and itself, of course it’s wobbling and deceleration has an impact. If you think it shouldn’t then measure time differently, for example as seconds since a certain instant
Isn’t that what the article is arguing we do? What practical benefit does keeping this historical definition of time give us? Outside of people trying to account for the rotation of the earth precisely who could even notice?
If you really need a 'solar-ish' time, you could also define a fixed function correction for UTC->'solar' and then extend that thousands of years by an order of magnitude. (Sadly the SI second is somewhat far off from the 1/86400th of a solar day, so a big portion of the correction caused by leapseconds is just this predictable portion of the difference).
> If you think it shouldn’t then measure time differently, for example as seconds since a certain instant
Plenty of stuff would love to do that, but we distribute UTC. To get back to "time from an instant" given UTC you have to know about and correctly and consistently handle leapseconds. It's quite tricky, because when an interface hands you UTC you don't know if the latest leapsecond has been processed in it. It's getting even harder recently because the widespready distributed systems failures caused by leapseconds are causing some people to deploy varrious kinds of "leap smear" which smears out leapseconds over some number of hours. Interfaces that are supposed to return UTC now sometimes return leapsmeared UTC with some unknowable choice of smearing scheme.
Arguably the root issue is that we've based out computer timekeeping hierarchy on UTC instead of TAI (or GPS time or whatever non-leaping thing). Had we based everything on atomic time and handled 'UTC' as a presentation layer thing like timezones are normally handled things would work much better. Unfortunately that ship has really sailed. Fortunately, if leap seconds are just not issued essentially everything keeps working without issue for hundreds if not thousands of years.
The handling of timezones and of leap-seconds are orthogonal problems, arising from distinct causes. Leap-seconds are a response to the desire to synchronise an atomic timescale with the uneven rotation of the Earth; timezones (and DST) are strictly a political problem.
Politicians often don't understand the consequences of timezone changes; they often introduce them without giving enough time for people to update their timezone database - sometimes just a few days. The result is that the new timezone is nothing more than a political gesture, because hardly anyone is using it.
I mostly agree with you, but this is a bad example. SQL injection is sadly still very far from a solved problem.
"We have solutions for the most common occurrences" is not the same as "the problem is solved".
What kind of non-argument is that?
the "comment" kind.
Oof classic 3rd rail for when you're arguing with CS grads
Leap seconds are a nuisance and source of bugs in a million programs. Fix them here, fix them there, it will always be wrong in the majority.
We've already done this before, it's called the Gregorian Calendar.
The problem described in the article where "time goes backwaards" only exist when you compare two different time sources, which is always risky, whether a leap second is happening or not.
UTC is a count of seconds. Conversion to HMS is dictated to fool with the S field, but everybody suffers. The seconds count is supposed to actually skip.
Because nobody is going to fix the million programs and gadgets that get it wrong every time.
Who said that time needs to be in sync with rotation of the earth? Nobody, who cares? It's a so small variation happening in a so long period of time to not be noticeable to any practice use: it's not that we take the sun as a reference of time anymore! We can keep counting time as we want and not be bothered with something not precise as the rotation of the earth. And for the applications that require that sort of precision, and only them, adjust the time accordingly.
I mean, a meter was once defined as the one ten-millionth of the distance from the equator to the North Pole along a great circle. It's not that for this reason if the distance between the North Pole and the equator changes we are all throwing away our meters... it's just that we found a more precise definition of one meter. Same happened with the second (and all the time measures, such as a day): we express them in a new format where it no longer matters what the earth and the sun do.
Humans sleep, usually at night time, and the rotation of the Earth defines night in any location, so regardless of the continual tick of some sort of "universal clock" we need a way to measure daily events that humans can use that rely on the sun going up and down at certain times and thus we need to adjust our local Earth times based on it's rotation.
Maybe we can decouple UTC (or whatever) from local times completely, so then a leap second is just a second we add to or remove from the offset for any given location, but we still need to deal with adjusting local clocks to the rotation of the Earth and it's orbit around our star, the "Sun".
This seems like a kind of navel gazing point, however-- without leapseconds it would take on the order of 4000 years to slip an hour, quite a big longer so that nights hours aren't aren't at night.
We already have a good mechenism for matching local sun time-- timezones.
I don't see anyting in your post to justify one second level offsets.
(aside, UT1 is technically defined in terms of earth's orientation with respect to distant quasars, not the sun :) )
These solutions (including daylight saving time, timezone, etc) were probably a good solution where the clock were local and it didn't exist the problem of synchronizing clocks all around the world. But to these day, it doesn't really make a lot of sense sense. Even timezone, it would be far easier knowing that there is only a world clock (UTC) and we adapt our time to the clock and not change the clock.
Timezone, daylight saving, and leap seconds generate a ton of problems only for a minor convenience...
We could wait enough leap seconds to reach 30 minutes and then have a smaller (or bigger) DST timejump and nobody would notice.
I think that's ok if "the future" is 1000 years in the future!
Though the ship has sailed, I think it could have been much better if computers were set to follow TAI Time (atomic clock time - unaffected by leap seconds) time than the UTC. UTC is as variable as localtime and should have been treated as such.
If fb wants to - they can (and should) use TAI time for system reference.
TAI : https://www.nist.gov/pml/time-and-frequency-division/nist-ti... edit: link
As far as I can tell, TAI will always be offset from UTC by an integer amount of full seconds, and I guess time coordination between large independent systems is mostly useful just when comparing log timestamps (I would guess almost all sensible software uses already account for much larger clock drifts than the current leap second count of 37, right?)
After adopting TAI, Facebook engineers just need to remember that their log timestamps are offset by N seconds from all the others.
Someone should fork the NTP protocol to use TAI instead, and go from there (or at least provide tai offset).
But that's backwards. A Stratum 1 NTP usually gets its data from GPS, which HAS the offset (GPS runs TAI). But it only outputs UTC, but not the offset, making other programs compute it from TZDATA. Why is NTP making user programs harder to get the data that IT ALREADY HAS? Because philosophically, NTP is married to UTC (even though NTP is mostly for computers!)
And providing this offset would basically get rid of a large body of people (like the TFA) who wants to CHANGE the definition of UTC, which is a more drastic proposal.
GPS time is actually 19 seconds behind TAI at all times.
1. Displaying current time: for that ideally you need the offset directly from the time server because the system timezone data can be out of date in regards to current time.
2. Displaying historical timestamps: for that you use the system timezone file.
There's a draft of the next version of the NTP protocol (NTPv5) at https://www.ietf.org/archive/id/draft-mlichvar-ntp-ntpv5-04.... which not only has the option of working in TAI, but also has explicit support for "leap second smearing". It also has a field to explicitly provide the TAI offset.
Every time I see ditching leap seconds come up, they never try to explain why TAI won't work for them, leading me to believe they probably just don't know it exists, nor could they even imagine something like it being invented.
https://en.wikipedia.org/wiki/International_Organization_for...
The same reason that KFC (Kentucky Fried Chicken) is PFK in Québec... In French: Poulet Frit Kentucky.
Honestly, it feels more natural for adjectives to follow the noun. I think about this a lot when naming variables.
English is a quirky language.
>Oddly, languages either have the exact same ordering as English, or the exact opposite as English. And, nouns in various languages fall in some designated position between the string of adjectives -- in English it's at the end, in Romance languages it's somewhere in the middle, such that most adjectives follow the noun, but certain adjectives precede
The real answer is that deeply learning grammar as a child makes you think in grammatically correct ways to begin with, which means that when you start vocalizing a sentence, it's already queued up in grammatically correct form or very close to it. This is why we should teach children grammar grammar grammar and almost nothing but grammar, using poetry for memorization, reading to expose them to grammatically-correct texts, and writing to drive grammar home. And some 'rithmetic.
mostly everything.
I am a native speaker, which means that I didn't realise that british english isn't actively taught. Like we aren't taught grammar in any particular way (apart from I before E, except after C, which is mostly bollocks, because it depends on the origin of the word. [their for example.])
Basically we are dipped in the language and we either succeed, or in my case dumped in remediation. (I can't spell for shit)
I didn't realise this until I was learning another language as an adult. They were usings terms like "present continuous, reflexives, compound verbs, etc" None of which I knew the practical meaning of.
Teaching a child to read, again you just realise that basically its 5 different languages smeared together, with shit all rules. Syntax, yeah we have some, but no native speak can explain the rules. (we have adjective ordering , but I don't know what it is, I can only tell you if you've got it wrong.)
Missing second half of the rhyme: "or when sounded like 'a' as in 'neighbor' or 'weigh'"
Nanoseconds since X is a fairly unambiguous reference (relativity aside).
Use this for any kind of timestamp or recordkeeping. Convert to UTC (or EST, CST, etc.) as necessary for reference to the solar day.
The only reason not to do this is because you have a million systems that are already running on UTC, and you don't want to do a massive leap second erasure to get back to TAI.
From a software development perspective this seems monstrously more complex than just muddling along with the current situation even with leap seconds.
First, consider the question of "what do unix timestamps mean?" The answer is UTC, except just be broken during the second where there's an extra leap second added or removed, and don't try to represent it. They neither represent TAI nor UTC perfectly, and have no way to encode a leap second, but they are very space efficient to store needing only 8 bytes.
Now, we want to start converting our systems over to TAI, great! To do that we need a format to efficiently store a unix time in a binary representation. For this exercise let's use Jan 1, 1970, and so when we call it we get a value today that's equal to unix time plus 37 (the current offset between TAI & UTC). Awesome, now we need a new function to call it in every single language we use, and then migrate all callsites over to it. Try not to miss any places where someone's passing unix time as an int64 instead of, say, a time_t. If you call into libraries that return timestamps make sure you shim them so that you can convert those timestamps from UTC to TAI.
Now, we have the problem of how to store those int64s. We can't store them in place of our current timestamps, they'll be 37 seconds off. So let's add a field to all databases where timestamps are stored to store the TAI version. Additionally, every RPC is going to need to send along both TAI & UTC during the migration process, so change those too. We can't just ignore cases where we need an integer representation of time, either - those have historically been the places where systems break during leap second changes.
I hope this gets to a little bit of why it would be extremely non-trivial to use TAI in place of UTC right now. If you're storing your time as, say, a string representation with a time zone built in you're right, it's actually generally not that bad, and time zone information is frequently encoded in the string. It's _extremely_ difficult to deal with once you move to a representation of time where the timezone isn't directly encoded in a timestamp.
I doubt anyone talking about the elimination of the leapsecond is unaware of TAI but TAI is not readily available on general purpose computers (and, increasingly, UTC is being silently substituted for leap-smeared UTC). And for specialized systems attempts to make pockets of TAI break down when they have to talk to the outside world (and have consistent times with it) and/or due to hardcoded leapsecond tables in software.
I would have loved to read more justification about _why_ Meta thinks we no longer need the leap second beyond calling it a community push. They did a great job of complaining about how hard it is to solve from a technical perspective, and then explained how they solved it. Is the only problem really that Meta doesn't know how to test a negative leap second?
> This periodic adjustment mainly benefits scientists and astronomers as it allows them to observe celestial bodies using UTC for most purposes. If there were no UTC correction, then adjustments would have to be made to the legacy equipment and software that synchronize to UTC for astronomical observations.
> While the leap second might have been an acceptable solution in 1972, when it made both the scientific community and the telecom industry happy, these days UTC is equally bad for both digital applications and scientists, who often choose TAI or UT1 instead.
The claim is that the benefits accrue primarily to a community whose relative importance is minuscule compared to the broader software world in 2022. The tradeoff was made in 1972, when astronomers etc represented a vastly larger proportion of software.
https://www.cl.cam.ac.uk/~mgk25/time/leap/
Time in the real world can use leap hours, the next of which will be in approximately 3000 years.
This is all quite hypothetical as it’s hard to predict whether anything like our current technological civilization will exist thousands of years from now, but even if it does, a simple mechanism exists to avoid problems (just have each jurisdiction change their local time when they decide they want to).
I can’t see any downsides for literally anyone from this proposal, other than the insignificant downside to the British that they will lose the prestige of being the place that global standard time is based on.
> lose the prestige of being the place that global standard time is based on.
You joke, but that's actually a source of some of the opposition. :(
It infuriates me that the BBC World Service insists on announcing the time as "<something> GMT", pronounced in a smug tone of voice. The GMT timescale no longer exists; nobody broadcasts it. What the announcers are broadcasting is the BBC's ignorance. I find it embarrassing and jingoistic.
They've also adopted an idiosyncratic way of pronouncing the time itself: "The time is Four, GMT". Everyone else says "Four O'clock", or "four hundred hours" or "four AM". The Beeb are almost completely immune to complaints; they've outsourced their complaints department, and the contractor's brief is to make sure no complaints reach programme makers.
Time may change forwards and backwards, because my computer clock may be fast or slow. The same logic to correct for leap seconds, can be used if my computer is 2 sec fast.
And your code had better handle it, and the os, libraries, it really is only hard ), if you have to support 1000s of novice devs.
Honestly, this issue screams education problem. "Time is a mess" should be taught alongside buffer overflow attacks and networking theory (in fact, networking theory is a great place to teach "time is a mess," because you can roll it in alongside ideas like "simultaneous action is a lie" and "clocks are always wrong anyway").
Already decades ago many have proposed to use only TAI internally in computers, instead of UTC, which is not a time.
UTC should have always been used only to compute the local times, together with the time zones, only for human interfaces.
There have been for decades libraries for using TAI instead of UTC, and even versions of Linux or *BSD kernels patched to do time keeping in TAI, not in UTC, eliminating all problems with the leap seconds.
Unfortunately the use of TAI has remained a niche, but that was the right solution.
If you want to use real-world time, you have to make sure it stays in sync with the real world. Switching to something which is close-but-not-quite-correct will cause even more issues than we are currently having with leap seconds. Can't deal with that? Well, just use the Unix timestamp like the rest of us?
Currently our calendar goes off by one day in 3236 years. If the history is calendars is indicative, in about 10,000 more years we may change our calendar. (Or, being multi-planetary by then, maybe we'll consider it a quaint relic of our origin.)
Our clocks predict astronomical time of day to less than a minute for a human lifetime. And both DST and timezones demonstrate that we're happy to live with the clock and Sun disagreeing by an hour or more.
My position is that both are currently good enough for the next couple of thousand years. And we can let our distant descendants sort it out when the time comes.
It’s more likely that every planet will have its own calendar and you’d have to do the conversions and translations. That’s what scientists do with Mars time. Thanks to relativity, time at point A is not the same as time at point B, and whether they stay in sync for you depends on how you get from A to B.
While "now" can vary according to the time it takes to get from A to B, all observers can work out what "now is according to the reference frame of the distant stars". On a mere interplanetary scale, this idea is amazingly precise. We might not agree on how much time passed (this has already mattered for GPS satellites), but for all practical purposes "now" is perfectly meaningful.
It's not that we'll never need another leap second; we could add ten, negative ten, or zero in the next 25 years and Earth won't care. Who will care are humans, who may get a bit annoyed when the sun starts setting in equatorial latitudes at 3PM.
There are some good arguments for keeping leap seconds, but I don't think research astronomy is really one (it might be more useful for amateurs), particularly on ~100 year timescales where you don't expect things to slip that much. I think this sentiment is shared by most of my peers, particularly those who actually have to implement data acquisition and analysis pipelines!
After all, there are still pieces of the original Bell organization and infrastructure around in active use, just with the names on the business cards and buildings changed. I don't think someone 50 years ago could have predicted which parts would still be around and which long gone.
Meta can simply stop applying a time offset in their reference, use TAI for forensics, and then have a separately calculated time when they need to display in that representation.
...Which is what happens already. System time is seconds since The Unix Epoch. All of those times are calculated and available, and always will be. They chose one of them, didn't like it, and invented a crummy workaround. They could've logged it in TAI and appended the TAI TZ to all their timestamps.
This is being done to work around poor coding choices they made, instead of making the computing fit reality. Basically "We chose smearing, which is a poopstain of tech debt, so we'll fix it by telling the whole world what time it is." That request is loaded with colossal hubris.
They might as well have the second redefined. The real operators do their thing and leave the squawking to those who want to self-identify a poor coders. Because if they don't want to account for a clock that jumps, then they're kicking the can down the road and they want everyone else to join.
Turning it into a Y2K or Y2038 problem is a sad choice of saddling bigger tech debt on the rest of the world.
Calling it mainstream is as much of a narrative as permanent daylight savings time was. The software solutions exist and were deployed (at least throughout Linux and main userspace) by the June 2015 leap.
This is a Facebook problem that they're sloppily handling by pushing it on literally everyone else.
How many times have you had an issue and resolved it by restarting a system or service without ever truly figuring out the cause?
That linked article doesn't mention leapseconds; it doesn't explain the cause of the disruptions, other than to note that it appears to be related to certain defective ADS-B systems.
(I'm aware of many others, though I'm not totally sure which might be subject to NDA so I'd prefer to use examples from the press)
If we want to actually solve the problem then let's switch to an interstellar time standard in a rest frame relative to the CMBR as far outside of gravity wells as possible and make that the universal monotonically increasing standard. Then computers can run on that time standard and UTC and friends can be derivatives.
This won't work: since galaxies aren't static, and because the universe expands, the point with the highest gravitational potential ("as far outside of gravity wells as possible") will both move w.r.t. the CMBR and have a gravitional potential that changes over time.
Across all the devices in my house that have a clock in them, the time drift is a little over an hour and it doesn't make the slightest bit of difference to me: internet connected computers being the most accurate.
Between individual computers, thanks to filesystem semantics, drifts of up to 2 seconds are expected and generally considered "identical" - it certainly doesn't matter for file sync applications.
So either we want to build a time standard that can be transformed in a sensible way to all the others which are useful - in which case something which works for interstellar timekeeping would be a sensible step, given that relativistic issues crop up even in Earth orbit, or we're building a time system "for humans" in which case everything we have now is fine, and will by definition be messy because time and timezones change all the time.
It's just for distributed systems the OTHER ways of dealing with the problems leapseconds create (e.g. using a local monotone clock) aren't available. But even where they are available leapseconds still create issues because they're extremely difficult to test and are often handled somewhat incorrectly.
UTC without leapseconds would in no way be less "for humans". After 4000 years of drift the effect on the solar noon would be about the same as you get driving to the next state over.
Leap seconds are still seconds so even with GPS sync, if all you're doing is tracking 1000ms increments then we have a format already which doesn't have them.
In unix time there are 86400 "seconds" per day since the epoch. On days when there is a leapsecond the timestamp of the leapsecond is given out for two (TAI) seconds.
A result is that unix time stays in sync with UTC and the difference between them doesn't change.
The belief that conventional unix time is somehow leapsecond free is a common source of leapsecond handling bugs. :( It results from misleading standards text which states that it doesn't have leapseconds, which it technically doesn't-- instead leaves the second undefined, which implementations distort to make unix time match UTC.
If your goal is to measure accurate durations, synchronize distributed systems, or point telescopes-- unix time will not solve any of your leap second issues.
It's plain weird to rewrite the world which doesn't actually care about leap seconds for use-cases which don't work in normal human reaction or processing times. 1000ms is a value only relevant to high precision applications, which are perfectly fine not being tied to a precise date or solar rotation or anything.
This feels like a programmers without science training issue: all models are models and you choose the one useful for your purpose. It's particularly galling coming from Meta who are large enough to just do this, write the code, and submit a standard for consideration by the tech-industry.
All we need to do is simply choose not to announce that all the software in the world that (might have) "got leap seconds wrong" but still has to talk to the other half that (might have) "got leap seconds wrong" will be officially broken, this year. Or next year. Etc.
Timex(TM) Watches, now featuring Puslar(TM) Time.
The difference between potential already need to get handled on earth. Esp. since the NIST labs in boulder are at about 5400 feet.
One of the largest electronic health records systems has code that predates the UNIX epoch. Much of the time handling code is custom written to deal with this. However, the code was so poorly written that the system would lose data during the double 1 am window that occurs during daylight savings time shift. Hospitals would just shut off all of their computers during this time to deal with it.
As the article notes, issues with leap seconds have also brought down reddit and cloudflare. Many people in this thread are treating this like some sort of display of incompetence, but if you've ever written code that deeply interacts with time, you'd know how difficult it is to get right. A sign of a good system is one where it is difficult to fuck up.
IMO it is better to guarantee that time always moves forward rather than trying to match computer time to human time.
https://www.nist.gov/pml/time-and-frequency-division/nist-ti...
It would be like silently changing the start of unix epoch time to 1800 instead of adding a new “Unix time since 1800” and asking people to switch.
This change only affects people who need UTC to be close to UT1 and also somehow don't know what UT1 is.
The people who would be unaffected by the redefinition can already just trivially switch manually (as we already assumed that just redefining things under them would work), leaving the UTC people alone. There is no good reason to silently break all programs carefully designed to use UTC correctly to fix all of the programs haphazardly written by people who did not know what they were doing and used UTC when they actually wanted TAI. Especially since fixing the wrong use of UTC is so trivial that we assume it can be done with no modification.
A few applications should switch standards, the question is whether solar concerned applications should switch to UT1, or continuity concerned applications should switch to TAI. The former is simpler, easier, cheaper, and only causes unexpected behavior (quite slowly), NOT systematic failure.
Not sure if you're playing Cunningham's Law or if you don't know this was the line of thought until everything was so far out of touch with reality, 10 days of time never existed, and official records were kept with dual-dates.
https://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates
https://www.timeanddate.com/calendar/julian-gregorian-switch...
Your example only speaks for the incompetence argument.
In reality, times and dates are really complicated. Luckily, the engineers at Facebook, Reddit, and Clouflare are being paid hundreds of thousands of dollars to show off their expertise. Is it that much to ask for them to read into details like leap seconds?
Would you say to an advocate of C (much less ... rust): Look man, real programmers write in boolean circuits. Programming is hard, sure, but the engineers at Facebook, Reddit, and Clouflare are being paid hundreds of thousands of dollars to show off their expertise. Is it that much to ask for them to read into details multiplication circuits?
:)
Leapseconds causing widespread failures isn't a hypothetical, just like buffer overflows aren't. Yet, in theory, with perfectly competent development ...
Yet even with perfect competence leapseconds are still pretty gnarly: They require systems have a trustworthy and consistent source of the list of leapseconds. ... and they mean that you fundamentally cannot predict the amount of time between two UTC timestamps when one or more of them is more than 6 months in the future... and no amount of competence can fix that.
For timers within a single system, use monotonic clock of your own cpu.
FWIW, there are many things that deal with leap seconds that way too. Too much risk of ending up in a difficult to fix or silently corrupt state, while coming up from a reboot is highly tested and known to work.
The cost of leapseconds is quite significant.
> but if you've ever written code that deeply interacts with time, you'd know how difficult it is to get right.
Good odds that even if someone has that they got it wrong and don't know-- especially when it comes to leapseconds as they're fairly hard to test esp. with distributed systems and infrequent enough that you may not realize the cause even when you've suffered from an issue.
start := time.Now()
// do something
spent := time.Now().Sub(start)
One man's bug is another man's feature.
This article details some of the problems: https://www.ucolick.org/~sla/leapsecs/dutc.html
(You may want to scroll down to "Implementing the plan outlined at Torino".)
If we end leap seconds, it doesn't take long - only until 2028 - until "midnight" is sufficiently far from "the middle of the night" that you will have to consider the legal issues caused by events that happen just before or after 0000 hours.
By 2055, the "minute" displayed on a clock may be incorrect, which again may cause issues with legal timestamps.
And by 2083, sundials are measurably wrong.
All because programmers wanted to save some lines of code.
Astronomy already ignores leap seconds in the same way that modern finance ignores half-crowns and shillings.
To explain a bit further: UT1 tracks the Earth's rotation relative to distant quasars and is thus directly the correct clock/reference to use for pointing telescopes. However it doesn't advance at a nice and stable constant frequency, but something that slowly changes over time (and can shift by strong earthquakes) and thus we approximate it with UTC, which runs at a nice constant frequency, but needs occasional correction to match up with Earth's rotation.
Changing to TAI means you are different from everybody else, and still have to fool with leap seconds to know what everybody else is using. Worst of all worlds.
(Except Google smearing, which is even worse than that.)
Yes, the actual problem exists, and ignoring/discarding reality (i.e. the "science" in computer science) will just cause further problems. If you and your modern stack of code can't handle the leap second, it's simply not production code.
I mean this is the whole contention. Meta's claiming this isn't actually a problem worth solving.
Sundials being "measurably" wrong become an issue at long spans. For example, no one wants solar noon to be at 10AM -- but that takes a while.
Solar noon in Spain is after 2PM already.
I agree, but I'm also - sad to say - less than surprised to find engineers at a Big Tech firm taking a high-handed, not to mention narrow and ill-informed, approach over the issue and trying to impose their will on a global scale. My worry here is that, Meta being Meta, they carry quite a lot of influence and may actually gain some traction.
EDIT: I'll add a bit more colour here. At the core of our platform we manage a database containing billions of legacy timestamped records (or events, if you prefer), adding more and more every day. Without even giving it a great deal of thought I guarantee you that this proposal will cause us more problems that it solves and will distract us from making more valuable investments of time and effort that would benefit our business should it be implemented. Sure, we can no doubt fix all these problems, but we've got better things to do. I imagine that many other businesses would be similarly affected and would take a similar view.
I wholeheartedly oppose it.
Big Tech companies/Anti Big Tech lobbyists massively oversimplify in their pitch to influential people to deregulate/overregulate certain areas. In both cases they end up making poor decisions for the general case both end up making the average case worse for everyone except themselves. It's about creating a market where none need exist. Facebook doesn't need to care about time really. It's not remotely important to their business.
I've built and worked on platforms with sub microsecond measuring requirements and this stuff didn't bother me. This is idle bad money finding work for itself at the expense of everyone else.
Disclosure: I am/was an early investor in facebook in 2012. Mark is turning it all to dirt because he's run out of ideas
Right back atcha.
We have three alternative time systems and a big bag of issues with each of them, but you think the extremely mundane argument that we should prefer one bag represents nauseating arrogance because you think that your favorite bag -- a different one -- is obviously correct? Come on. Do better. Be civil.
That is effectively proposing the deletion of the most commonly used time system of the three primary time systems from existence and forcing everybody and all existing systems that use it to convert to what is effectively TAI.
That is not mundane. Mundane is arguing that everybody should use TAI. Arrogant is arguing that we should force everyone to do it by redefining their dependencies under them.
Arrogant is imposing a big nuisance on everyone every year or two. It is not arrogant to ask for a nuisance affecting millions to be dropped.
If there was a scheme that fixed only the wrong usages, that would be fine. But, it is frankly absurd that we should even consider breaking carefully designed programs correctly using their dependencies to fix programs incorrectly using their dependencies especially when it is trivial for the wrong usages to be fixed manually.
Not announcing any more leap seconds will break exactly nothing.
People using the wrong dependency should fix their system to use the right dependency. They should not campaign to steal the name and replace it, that is absurd.
The only people who care or need to do not use UTC. They use TAI, and a separate continuous log of fractional seconds.
UTC has one role, and that is Standard worldwide civil time. Telling people who need Standard civil time to use TAI makes everything strictly worse: not only do you then not match most of the world, but you still have to track irregular, unpredictable corrections to be able to sync with everybody else.
That is what is proposed to be fixed and that you are arguing against for reasons you don't know or, apparently, care about.
Switching civil time to TAI would break everything, most of which cannot be fixed. Random breakage is the problem. More breakage would be strictly worse.
That's just... completely incorrect and totally false? Have you ever even worked for a business? Have you ever read how time libraries are actually written?
Please, go read the Python `datetime` library: https://github.com/python/cpython/blob/0fe645d6fd22a6f57e777... which is used to calculate a UTC timestamp: https://github.com/python/cpython/blob/0fe645d6fd22a6f57e777...
It is literally built on the exact assumption that 0 means January 1, 1970 and that right now is (number of seconds in a day) x (number of days since Jan 1 1970). If we stop adjusting UTC, then by this time next year UTC will be one second out of date with our wall-clock times, and calling `datetime.now().isoformat()` will give us a timestamp that's 1 second off from the wall-time of a user. At one-second past midnight on the 20th of the month, your computer will incorrectly be spitting out timestamps saying it's exactly midnight of the 19th. That's what you might call a major breaking change.
Says something about how Facebook sees itself, I guess.
Leap seconds are exactly the "screwing around" you criticize.
Neither do I in day to day life. But I do have to care about it when I or members of my team write code, or store and retrieve data to and from a database, or work across multiple timezones, because it can be critically important to unambiguously know whether something happened on one day or the next.
The reality is there aren't any nice, elegant solutions to this problem. Leap seconds aren't a nice solution. Meta's proposal isn't a nice solution. I don't necessarily even think it's worse than leap seconds, but it's certainly not substantially better. The key point is it's a change and one which, in my view, won't deliver enough value for everybody (beyond just Meta) to justify the level of disruption it will certainly cause if implemented.
Let's paint a picture based on actual code I've actually seen in the real world. If you ignore the leap second but keep using UTC, then in about 5 years, UTC will differ from wall clock by about 5 seconds. So if, in some software used for, I don't know maybe billing customers, someone was calculating day boundaries by doing modulo division of UTC by the number of seconds in a day (I've seen it), then in 5 years we've got a 5 second discrepancy in the number of API calls made by customer X when comparing what the software says to what the customer measured. Customers don't like this, accountants and lawyers REALLY don't like this, and us engineers will have the wonderful experience of telling them all
> "this code used to be valid until some boneheaded engineers at Facebook convinced a ton of other engineers to break the agreed upon standard about what it means to measure time in this way, and now things that used to work fine need to be patched because we've got a Y2K EVERY DAY!"
Oops, I guess ignoring wall clock time might be something other human people care about after all.
I'm not following here. What defines "legal timestamps" in our current system? I'm unaware of any laws in the US that uses the actual position of the sun to determine the time.
"Noon" when the sun is at the highest point, can vary over an hour across a timezone.
this is "solar noon" - just "noon" denotes 12:00 on the clock [1]
[1]https://www.bsu.edu/academics/centersandinstitutes/ceres/hel...
Shifting the timezone by a couple seconds does not prevent or hinder cataloguing events in any way whatsoever, certainly not more than switching to daylight savings time does or the mere existence of timezones, which may easily be half an hour or even more off from the solar time - the offsets we use for time are effectively arbitrary already, and adjusting the arbitrary choice of the offset by some seconds is not a fundamental difference. Event timestamps already map to different days depending on different timezones, you do need to know which timezone your clock is using, of course, but you already need to do that.
> This could affect everything from university applications to boating licenses to social security.
Last time I looked, a boating license required you to be a certain age. Dec 31 and Jan 1 are still just as far apart as July 6 and July 7.
I'm not sure what you're getting at here. If we stopped introducing leap seconds, then why would the legal world still care about them?
_Some_ legal uses of time are probably concerned with this, but I'd think it's a pretty small minority.
Or even have legislation to agree on that and set single law.
By precedent, UTC seems the logical choice for the one time system.
Telling people to use TAI is telling them to have a different time from everybody else. The whole point of civil time is specifically that other people use it. Using TAI does not free anybody, because anytime you need to interact with outside, you are back in the nightmare.
I've tried to build systems using TAI they break down because: At some point you have to interact with something that doesn't use TAI and that fully reintroduces all the leap second issues, and because a lot of third party software has leap second handling, so the wheels fall off when you update some component and its embedded list of historical leapseconds now changes its behavior. Similarly, sometimes UTC time is all that's available and without the leap second data you can't back them out to get TAI.
And with leapsmear the challenges of backing out to TAI have increase substantially.
And the best way to do that, is to simply define UTC, to be TAI. Thats the point.
This isn't just about lines of missing code. This is about forcing subterranean or submerged computers to surface. This is about out of sync clocks across information propagation networks across planets. This is about real lives that are ruined because time stamps didn't quite line up, causing delays, deaths, and needless headaches.
It doesn't need to be this way. We could just accept a minute of the clock being off from "true" midnight, which doesn't even make sense to me given that few people are right at the astronomic point where midnight is "true" midnight for their timezone. Heck, China is one big giant timezone so who is this actually for, really? The people that care about sundials? Most people don't even grow their own food.
We're no longer a sun-driven economy. Well coordinated timekeeping across devices that may not always be able to transfer data is far, far more important. If it's sufficiently wrong by the year 3422 then we'll deal with the fifteen minutes of annoyance then. This is a crazy premature optimization.
How do you have a well coordinated clock without being able to get four bits [1] per year of leap second data? It's hard to keep within one second of a time standard over 6 months or a year without communication.
[1] bit 0: was there a leap second in the most recent period, bit 1: was it positive or negative; bit 2: will there be a leap second at the end of the current period, bit 3: will it be positive or negative. Bike shed my fictious encoding if you like, but it's good enough. Use a whole 8-bits, go wild.
For “midnight” being far from “the middle of the night”, that’s already a reality for many Chinese living far enough from Beijing, or god forbid regions where “night” doesn’t mean much for half of the year.
For all intents and purposes, if a formal definition of time isn’t practical people come up with their own ways.
And then there is continental shifting... Which we also don't account for...
A few seconds or few minutes really don't make that much difference for average person.
Since the article was published we've gone from positive leap seconds every so often to looking like we may get the first ever negative leap second: https://upload.wikimedia.org/wikipedia/commons/f/fb/Leapseco...
Which means the article's estimates on how long it will be until we're off by a given amount of time are very much obsolete.
[1] https://web.archive.org/web/20030801000000*/https://www.ucol...
Some people: astronomers and orbital mechanicos are obliged to care about sidereal time, regardless. Making me deal with it too is pure tax with exactly zero benefit.
No, it's because programmers don't want basic timekeeping in all devices involve the worst issues of managing a distributed system.
The worst case scenario is things are different.
Timestamps are exactly what we define them to be. There is no correct and incorrect.
One option is to have a system with arbitrary unpredictable leaps to keep it synchronized to within 1 second of the mean solar time over Greenwich, England. Every computer system that has to deal with time accurately needs a lookup table for leap seconds that is occasionally amended, with only a couple months warning in advance.
Another option is to just let the clock run at a constant rate. In this case only astronomers have to keep track of the difference between solar time and clock time (which they already do anyway).
The fact that the difference will increase to an hour after several hundred years is utterly irrelevant. If people in the future care, they can simply adjust the timezone definitions to compensate, since timezones are already adjusted all the time.
Yes. Problems with delay time going negative usually come from not using CLOCK_MONOTONIC for delay time. CLOCK_MONOTONIC is usually just the time since system startup. It comes from QNX (which, being hard real time, had to deal with this first), made it into the POSIX spec around 1996, and is now available on all major OSs. But there's still software that uses time of day where CLOCK_MONOTINIC is needed.
Then there's the smoothing approach. This document described Facebook's smoothing approach, which has a different smoothing period than Google uses.
* Facebook/Meta: "We smear the leap second throughout 17 hours, starting at 00:00:00 UTC based on the time zone data (tzdata) package content." This is puzzling. What does the time zone package have to do with UTC?
* Google: 24-hour linear smear from noon to noon UTC.[1]
* AWS: Follows Google.
* US power grid: Starts at midnight UTC and takes a few hours while all the rotating machinery takes 60 extra turns to catch up.
Not sure what telecom is doing.
The IANA TZ database includes information about leap seconds, and even supports the concept of "right" time zones in which the leap seconds are counted in the Unix timestamps. (Which violates the unix spec, and may cause problems with code that assumes it can do path like `1 day= 24*60*60`, but on the other hand, things like DST already make that unsafe).
It is mostly likely simply the case that they are using the leap second data from the time-zone database as a convenient source of this data.
Why 17 hours instead of 12 or 24? Something to do with 17 being a prime number or some convenient divisor?
> In about 600 years TI will be ahead of UT1 by half an hour, and in about 1000 years the difference will be a full hour.
That's nothing. Time zones alone already create significantly larger errors. Belgrade and Sevilla share a time zone, but the solar meridian ("noon" on a sundial) is 12:44 in Belgrade and 14:30 in Sevilla. Obviously, the same error is present in the astronomical "middle of the night". This does not, in fact, create "legal issues" for Serbs or Spaniards.
In 600-1000 years, around the time that it would actually matter, we're going to have to reform the time system anyway to account for relativistic drift between the surface of the Earth and human settlements elsewhere in the solar system.
You FAR overstate the impact on civil society of failing to change it by a second every so often.
Ironically even astronomers, who leap seconds were originally for, don't benefit because they need to know the Earth's rotation accurately to subsecond levels.
Honestly from my perspective, 3am is the middle of the night (night-morning-afternoon-evening starts at 0-6-12-18 for me) and somewhere between 4 and 5 most people are probably asleep and the date change should occur. I can't count how often I've heard people clarify what 'tomorrow' means when the word is spoken after "midnight" but before going to sleep.
But yeah gotta pick something for the date change, it won't be worth the cost of change now. If we do end up ever switching to something like decimal time, this should be on the todo list though.
And I know "midnight" is historically supposed to be about the sun being the furthest from its zenith rather than in the middle between when you go to sleep and get up, however that occurs somewhere around 1am here (01:41 at its extreme, from July 17 till August 5th). If that's not enough to warrant a redefinition, 27 seconds accumulated since we started counting leap seconds are also not enough to warrant an update yet (following Facebook's logic here).
All these arguments based on sun position make no sense in a world where people already live in places where the sun literally never sets or never rises for months, and people already live in time zones offset many, many hours from "correct" time. The sky doesn't fall!
That article is ridiculous.
* "Most telescope pointing systems fail" (by 2027) (with 5s deviation from earth rotation). Pointing systems cannot blindly rely on UTC anyway, since (a) even with leap seconds UTC is up to 1 second off earth's rotation, and (b) pointing a telescope depends on where the telescope is on earth, so some offset must be added to UTC by some human.
* Hypothesized legal issues... give me a break.
It would be much less trouble for humanity to deal with this once every 100 years or so.
I can't follow your logic here. In any relevant context midnight has a definition, typically UTC midnight in the applicable timezone. Eliminating leap-seconds would make the instant midnight occurs less ambiguous in 2028, because precise timing with leap-seconds is strictly harder than without. (and one can independently realize a time that closely follows TAI but one cannot independently realize UT1 without a VLBI radio telescope array, and one can't realize UT1-TAI without a datafeed because the decisions are subjective).
This isn't just a question of 'some lines of code'. Leapseconds cause widespread disruptions even when they don't occur, they cause security vulnerabilities (and slower and less secure systems because they make synchronization unreliable). People are widely deploying "leap smeared" NTP servers to try to prevent some of the worst synchronization faults, but doing so makes it impractical to back out leap seconds to derive TAI (or a more accurate TT) from the system's UTC, particularly because systems don't know if they're leapsmeared or not (and different smear sources use different smearing parameters).
Also, why were non-linear smears thought to be desirable? Googling just turns up hand-wavy phrases like "easier on clients".
I found more details and motivation in this article: https://developers.redhat.com/blog/2015/06/01/five-different...
> current non-smear time
This is the server that keeps that time! ;)
But IMO, the time keeping device should be a separate hardware module with battery backup that is never is restarted.
The computer should not be keeping time to begin with.
My only guess is that because smearing takes place at Stratum 2, if the network partitions part of the NTP servers downstream (Stratum 3+), they'll have an offset as large as T/(17 x 3600) (T being the partition duration in seconds). Yet I guess it must be something else for I cannot see why that won't be tolerable.
More generally AFAIK the NTP RFC does not include smearing period, which is why the best practices are to only use smearing in a well controlled environment rather than on public facing NTP networks, but why is this not something that can be fixed? I'm not sure.
Why not just agitate for a move to French Revolutionary Decimal Time as well?
even with the best and brightest engineers there is a non-trivial probability that someone will make an assumption that is invalid based on their understanding of what can happen (ex. leap seconds never go negative!) or the library their using (this ensures monotonic time!) that could lead to disastrous results. and especially at meta scale, that probability is no longer "will someone make this mistake in our code?" but is "how many times will people make this mistake in our code?", so systemic solutions that eliminate this as a class of problem an individual can create is something we should consider.
You mean some influencer's timeline could get messed up? The horror!
there are also all the other companies out there who do not have the platform that meta has that can also hit the same issues. i'm sure some of them have products you wouldn't be so glib about.
Only facebook here is the one suggesting we should change things, so who is using facebook as critical infra and what is your definition of "critical" here.
If a 21 year old grad can move 200 terabytes of historical data 15 years ago what are the best and brightest at FB doing with their lives?
This is one of those cases.
It’s therefore just not possible to easily equate coordinates of civil time with physical time, and the related facilities in software development shouldn’t project an illusion to the contrary.
The topic here is worldwide standard time, literally the same for everybody, and whether a million programs obliged to make tiny adjustments to it on a random, unpredictable schedule was a good idea.
Anything fiddly and unpredictable a million programs have to get right will instead be got wrong.
t0 = time.now()
/* do stuff */
t1 = time.now()
elapsed = t1 - t0
But perhaps clock smearing is genuinely changing the way systems measure time, as opposed to smearing how the system renders t=1658818054.0 as hours, minutes and seconds? That seems implausibly incorrect. Lining up the minute hand with the noonday sun on one particular part of the planet should not possibly have any impact on measuring how long it takes to compile my code.
Here's what POSIX has to say [1]:
> 4.16 Seconds Since the Epoch
> A value that approximates the number of seconds that have elapsed since the Epoch. A Coordinated Universal Time name (specified in terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is related to a time represented as seconds since the Epoch, according to the expression below.
> If the year is <1970 or the value is negative, the relationship is undefined. If the year is >=1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all integer types:
> tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400
> How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time is implementation-defined. As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds.
> Note: > The last three terms of the expression add in a day for each year that follows a leap year starting with the first leap year since the Epoch. The first term adds a day every 4 years starting in 1973, the second subtracts a day back out every 100 years starting in 2001, and the third adds a day back in every 400 years starting in 2001. The divisions in the formula are integer divisions; that is, the remainder is discarded leaving only the integer quotient.
The key point to hang on to is that in POSIX "seconds since the epoch", a day is always 86400 seconds long, and midnight in GMT is always an exact multiple of 86400 - and so the value of "seconds since the epoch" must necessarily be bodged to account for leap seconds. It is not a monotonic, linear measurement of the passage of time.
Another angle on this is to look at any date and time library you fancy. To convert from linear seconds-since-the-epoch time to a human-readable timestamp, they would have to obtain a leap second correction from somewhere, and apply it before doing formatting. There is no date and time library which does this. Because they all expect a nonlinear, UTC-aligned seconds-since-the-epoch.
[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
https://www.timeanddate.com/time/negative-leap-second.html#:....
If dUT1 can become either negative or larger than 1, all such hardware and software must be reviewed and possibly upgraded, to no longer make assumptions about dUT1.
Communication protocols may have to be changed, if there is no way to encode a negative dUT1.
Negative values should already be accounted for, afaict.
> UTC is maintained via leap seconds, such that DUT1 remains within the range −0.9 s < DUT1 < +0.9 s.
I can't imagine why it would ever be constrained to abs(dut) < 1, as that does not appear to be a hard spec anywhere, it's just the goal. But I could see some really stupid implementations, so maybe.
The only people who need to pay attention to sun angle are astronomers, and they use their own system based on TAI.
So you are arguing to continue rejiggering a complex and error-prone system that benefits exactly nobody.
The hubris of “we’d rather not do this, so let’s make the entire rest of the world deal with it instead” is impressive.
We do lots of things that are hard because doing them right is often more important than doing them easily. Switching from ASCII from UTF-8 was a pain, but we did it. Software upgrades are a pain. Security infrastructure is a pain. Timezones are OMG such a pain. But in all those cases, we collectively said “welp, guess we’ve gotta do it”.
And what Facebook notably didn’t propose was a way to actually make this happen. Who’s going to project manage the global coordinated effort to migrate the planet to Facebook Time? That sounds like much more work than them just fixing their time handling.
I agree that we don't just need to do something because fb wants to do it, but it might actually be worth having a discussion over.
But I don’t feel like this rose to the level of an actual proposal. It was very short to assert a claim with such wide-reaching implications as “we should start ignoring leap seconds”. As such, I don’t think it calls for an in-depth rebuttal.
Consider:
Proposer: “It’s time to leave Unicode in the past. It requires us to update every part of our system to deal with UTF-8 strings instead of much simpler ASCII, and we’re spending a lot of resources. Because it’s so hard and expensive, we should all use well-tested ASCII code. People who want to interoperate with our system can just rename themselves to use the Latin-1 alphabet.”
Everyone else: “No.”
Yes, it is hard, and people have spent a lot of, ahem, time and money to figure out how to manage this at scale. But there are real-world-tested approaches to dealing with the issue, and I firmly believe it’s better to work out and coordinate on the remaining rough edges than to throw the whole thing away to make a handful of engineers’ jobs easier.
"A small number of countries however, including Russia and the United Kingdom, want to keep the leap second."
UK used to decide on which date to switch to and from "summer time" every year. "The admiralty will take up the question in coming weeks."
Source: I managed to make a transition from UTC to TAI in a broker trader in 2009 when I was fresh out university.
The world is messy, life is messy, and so is everything else. If that’s too much for poor programmers, they need to find another job.
I obviously meant “re-engineering”, but “de-engineering” works as well, in this case…
"Let's just kick the can down the road" isn't solving anything.
> "As an industry, we bump into problems whenever a leap second is introduced."
Their suggested solution is:
> "As engineers at Meta, we are supporting a larger community push to stop the future introduction of leap seconds and remain at the current level of 27, which we believe will be enough for the next millennium."
Most folks are rightly pointing out that there are many other solutions that we could introduce, which wouldn't have the downsides of UTC drifting away from our wall-clock time. Facebook didn't even discuss those solutions though.
An example possible other solution: programmers (especially programmers at Facebook) should stop using UTC and should instead use TAI (which is literally UTC but without leap seconds). Indeed, using UTC time as anything other than a wallclock time should trend towards the norm. Even though this is a clear tru-ism, seeing it adopted would be way harder (due to language inertia and habits) compared with just changing the standard (nevermind that changing the standard would break a ton of logic built around expectations like "midnight UTC falls on an integer multiple of 86400").
The purpose here is for things to get better, not worse.
* https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove...
Of course there's a whole lot of other userland code besides ntpd.
Better would be half of everything not breaking every 15 - 30 months.
> 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.
> ... The tech giants and two key agencies agree that it's time to ditch the leap second. Those are the US National Institute of Standards and Technology (NIST) and its French equivalent, the Bureau International de Poids et Mesures (BIPM).
And, maybe, don't run sub-second benchmarks with a wallclock.
Of course it was Google who picked the worst of all possible choices.
You might call the biggest earth-moving company in the world and see if they will give you a quote for that.
Humans want noon to be when the sun is overhead, and midnight to be the middle of the night. Almost nobody cares about sub-second accuracy or monotonic time. Track it that way internally if you like, but humans want time to correlate to what they see out the window.
So, if we stop actually caring about normal time, why should we care about leap seconds either...
It is exactly the problem. Why should every software system everywhere have its own complicated, unpredictable, error-prone fudge that benefits literally nobody?
Personally, I would like to keep leap seconds. The only change I would make is to demand a longer notice period: 18 months instead of 6 months would be good. Presumably that would mean we'd have to tolerate a slightly bigger difference between UTC and UT1 but that seems all right.
It would be stupid and irresponsible to abolish leap seconds without deciding on and implementing an alternative way of keeping time, and therefore the calender, in phase with the cycle of daylight. There are alternatives (leap minutes, redefining the second, ...) but to me they all seem a lot worse than leap seconds.
Of course, whatever we do in the future, software will still have to handle leap seconds for processing timestamps in the past so any change to the system would mean that most software gets more complex.
Reaction: let's stop using the system we have some practice at doing, and instead open up the question again, but really just have big tech corporations dictate to the world that we need to do something else.
Choosing not to impose a hassle and source of bugs on millions of people every year or two is obviously correct.
Anyone who wants to use what astronomers use will still be free to do that, without bothering literally everybody else.
Timezones are already backed by a database which needs regular updates, including leap seconds would make sense since those are also updated in an unpredictable manner.
1. We move from using leap seconds to leap minutes.
2. We move leap minutes to timezone offset, because time zones are already a clusterfuck and you can't make them any worse anyway.
3. One-time adjustment to all timezones to get the system started.
Result: Z timezone is equivalent to TAI. When you want to account for planet-related BS, you apply a timezone offset.
You can definitely criticize this, but with a caveat: if you believe that Unix timestamp doesn't have leap seconds or that timezones only come in 1-hour increments you clearly have no idea how computer time really works and should probably read up on that first.
If you have a source for leap seconds in Unix timestamp, please post a correction to Wikipedia.
https://en.wikipedia.org/wiki/Unix_time
UTC has leap seconds, and so Unix time can be converted to UTC, for the era in which UTC-with-leap-seconds is defined (after ~1972)
Imo society needs three distinct time counting systems.
1. Linux time. Essentially a universal addressing system for the measure of time in a agreed upon reference point (Earth’s surface). This should be the standard for science/computation, with the need for language to describe time dilation when comparing two reference points. Unix time doesn’t have leap seconds, or the concept of days.
2. UTC aka civil time. Things such as the orbit of the sun and the rotation of the earth aren’t in constant speed and don’t divide evenly with each other. UTC deals with short term variability with leap days and leap seconds. This is so every January 6th the earth is roughly in the same spot relative to the sun, and every 5pm the earth is in roughly the same part of its rotation. This is important because these things drift on human scale timelines. This calendar should be used for daily life, business, etc.
3. A purely astronomic calendar. A calendar that defines time by astronomic events. For example, defining a day as one rotation of Earth and not as a number of times an atom vibrates. This should be used so we can discuss astronomical events such as “A Martian year” or a “Saturn Day” and provide some meaning. This is the basics that should be taught to elementary school children to establish the cultural meaning of a day or a year and to provide some basic learnings of nature.
It is the number of seconds that have elapsed since the Unix epoch, excluding leap seconds.
If we used a unix-time-including-leap-seconds instead then the date/time conversion functions would need to have a little extra smarts (a table of leap seconds in addition to a timezone database) but most of the leap second related problems would not exist.
(We already deal just fine with months having variable numbers of days. Minutes having variable numbers of seconds is obviously awkwardly rare from a testing point of view, but not fundamentally more difficult to get correct.)
The fundamental difference is that we can predict well in advance how many days will be in a given month, and the rules for calculating that number can be implemented with a short lookup table and a few modulo operations.
The lookup table for past leap seconds, however, is already longer than 12 entries, and there is no way of calculating the length of all future minutes.
On the other hand, the problem may be simpler than keeping track of changes to timezone definitions, since there are hundreds of jurisdictions that can unilaterally change those.
0. Human diurnal local time
1. Universal time similar to 0. but without local offsets - UTC (UT1)
2. Universal monotonic time (within comparable gravitational reference zones) - TAI
These already exist. There is nothing to add or remove, but to do things differently that have already been recommended rather than sticking with insane traditions for another 25 years wherever possible. UTC (UTn), GMT, are insane for timestampping.
Use TAI essentially everywhere and calculate it later as UT1 or local time. If you fail to do so, you risk discontinuities and security vulnerabilities. This is why you should and must use TAI64[N[A]] rather than UTC because UTC is not monotonic. You can get UT1 from TAI by downloading LS tables and doing the math yourself. It is rare to find UTC-centric code implemented correctly.
This isn't rocket science, it's first principles of recording data that doesn't vary nondeterministically in forward time.
Also, Chesterton’s Fence.
Translation: We suck at computers and think you all do too. So let's just bury our head in the sand and make some cash before it all falls down.
I'm being glib, but come on guys. You're trying to tell me that your crummy programming and cash flow is more important than the literal spinning of the Earth.
You can try all you want, but the sun will set when it does, your clock be damned.
I may be a rare person on HN that actually has dealt with these leaps from the 'source'. I used to work for a pico-second accurate timing company and had to go through the microsecond adjustment due to the March 11th, 2011 earthquake in Japan. The company was a backup site for the NIST clocks. I've even worked with the second at NIST. Yes, that little port at about eye level that the whole US uses as it's second. You can't take things out of the room (like asbestos) and you can only be in there for short periods, it's that sensitive and important.
All that said, the Earth is a really crummy clock! But guess what? You can't fix that. It's mother nature's world and we just live on it.
If FB thinks that trying to get everyone to quite literally 'not look up' is going to work in the long term, they are in for even more headaches than they already have. Many, many industries and sectors must use hyper precise clocks and they must be aligned with the Earth's rotation. If are not, then they will drift psuedo-randomly apart as all clocks do. And then you're screwed when you try to get your own little clock system to talk to other clock systems that have been drifting too. You think you have issues now with imagined negative leap seconds? Wait until you try to define time.
Which says both Google and Amazon smears over a 24 hour period (in contrast to Meta's 17 hour smear).
Just because we suck at codifying things doesn’t mean we should change the goal to make it easier to codify. If you need a more straightforward clock in your software, use just TAI or something, instead of trying to redefine calendars.
Cache invalidation and naming does not come close imo.
Some discussion of the issue and the fix implemented start around here: https://github.com/golang/go/issues/12914#issuecomment-26993...
And isn't Unix Epoch derived from some sort of Atomic clock standard? I can't remember, but it seems all of our systems time should be atomic time, then you can derive UTC or whatever you want from that.
This is, in every way, not a problem they have to cooperate with anyone else about.
EDIT: also, Unix Epoch Time, has never had leap seconds. The standard is defined as UTC exactly at the start of the Unix Epoch and ticks at 1 second since then. So from that perspective, and the perspective of every sensible internal clock system in programming, you already don't have a problem.
That seems to be a solvable engineering problem. One could make sure the server is up to date on all recent information before taking it back into service. It's a similar problem as making sure that cache servers that have invalidated data don't go back into service before their cache is updated - which is tablestakes for services like CDNs.
I guess the problem here are public servers that can't run software that understands doing that? I see the challenge for those, but maybe something like an improved version of NTP could fix it?
Imaginary civil days would always have exactly 3600×24 seconds. We could always convert any past date easily with a small table. We could convert any future date with reasonable accuracy just based on extrapolation.
No ambiguity, no jumps, we still stay roughly in sync.
We could even just use 10 year blocks so that in the short term, most projects would have the entire future conversion factor timeline known at the start.
The idea that this problem is so hard that users have to be inconvenienced to the point that reality is ignored is a bit strange to me.
Only TAI is a time.
Already decades ago, some programmers have argued that internally all computers and their software should use only TAI, which is a time, so it behaves as expected, while UTC must be used exactly like the local times and the time zones, only at the interfaces with humans.
If that proposal would have been adopted, there would not have been now any discussion about the leap second.
The only reason for the existence of UTC is to keep dUT1, i.e. UT1 - UTC, under 1 second.
If the leap second is eliminated, then dUT1 will grow over 1 second, so there are other cohorts of hardware devices and software applications that must be updated in order to no longer rely on the assumption that dUT1 is less than 1 second.
Anything that has any relationship with astronomy, e.g. for observations or for navigation, relies on computing UT1 (i.e. the angle between the mean Sun and Earth) from time, so it would have to be updated.
Changing the definition of UTC would make it completely redundant, Instead of giving up to add leap seconds to UTC, it would be much better to make a final leap of a half of minute and have TAI = UTC after the date of the big leap.
Having 2 identical times with an arbitrary offset between them would just add needless complications to all time-related software, forever.
Could you elaborate on what you mean? What is UTC if not a time? Like, datetimes vs time?
Even if Unix time was based on TAI, you'd still need leap seconds in order to resolve the correct local time (which is based of even-minute offsets of UTC). Maybe it's easier to deal with in calculation post-hoc vs smearing on the day of, but that handful-of-accruing-seconds will always be there.
The mean Sun is a fictitious Sun with a motion that is averaged in comparison to the real Sun.
UTC is the UT1 angle rounded to a multiple of 1/21600 of a right angle, i.e. the angle corresponding to 1 second of time for something that completes a circle in 1 day.
Because of this rounding, actually a truncation, UT1 = UTC + dUT1, where dUT1 is between 0 and 1 "seconds".
Even if UT1, dUT1 and UTC are expressed in "seconds", these "seconds" are not the unit of time, but like I have said, such a "second" is 1/21600 of a right angle or pi/43200 radian.
Both UT1 and UTC are angles that approximate the longitude of the projection of the Sun on Earth, with various accuracies.
Because the rotation of the Earth, which causes most of the apparent motion of the Sun, is almost uniform, the angle of rotation is almost proportional with the time, so the angle UTC is almost proportional with the time, i.e. with TAI.
Because of the way how the "second" angle used for UT1/UTC is defined, the approximate proportionality becomes an approximate equality of TAI with UTC, but because the equality is only approximate, there is an increasing offset between them.
In the ancient times, the people did not care much about time, but only about the angle of the Sun, which determined when it was light or dark, hot or cold, enabling or preventing various activities.
In modern times with artificial lighting and heating and with many activities that proceed at predictable rates, time has become much more important than the angle of the Sun.
In any case, in all contexts we must be aware that the angle of the Sun and the time are not the same thing, even if they are almost proportional, i.e. almost equal after a change of the measurement unit.
That's like saying a watch or even an atomic clock doesn't measure time, it measures oscillations. It's being pedantic to the point of obtuse.
UTC has exactly one purpose: to be a common reference for everybody else. Making it not mess up everybody else, every year, is obviously the better choice.
You may stop beating your spouse now, and it will be purely an improvement.
Having made the mistake 27 times already does not justify making it even a single occasion more, never mind forever.
It’s inevitable because we don’t want hours of slip on Earth and eventually we will move to other planets which certainly don’t want Earth leap seconds.
If we can’t deal with IT that improperly models the universe, the right answer is not to change the world to be more like the shitty naive model the software implements, it is to be less dependent on the technology agreeing 100% with reality.
I want everyone to use UTC and align local lunch times to solar noons.
Sticking with local solar time in the age of jet planes would have been at least as much fun as daylight saving time.
If the current drift would continue then we're talking about a drift of 9 minutes every millennium; less than an hour for all of recorded history (and it mostly likely won't continue as-is; sooner or later we'll get negative leap seconds).
This creates a fundamental problem. It is now universally agreed that atomic clocks provide a much better measure of time than does the Earth's rotation, yet for human comfort, we would still like time to stay in sync with the Earth's rotation. How to accomplish this?
Meta is not arguing against adding the leap second, they just argue that skewing the clock slightly over some hours avoids the 'invalid' time with 61 seconds in a minute and the resulting software problems while keeping the time reasonably accurate for for the general public and computer systems.
It's bonkers, but so is just asking metrologists to stop being so darned concerned with accuracy of time measurement because its causing Facebook to spend money they'd prefer not to spend.
This feels very can-kicky, even if the can can be kicked a thousand years down the road. I don't think more can-kicking is really the best solution.
I've been on the front lines of adapting code for a novel timezone change. It wasn't pretty.
Wtf is this attitude of modifying the definition of time to fit your engineering needs where there’s a perfectly available alternative quoted in the article.
I really don’t get it. If you don’t like leap seconds use a definition of time that does not have them. Why modify the only standard with leap seconds and annoy everybody else?
It's embarrassing they can't figure out how to use the well accepted monotonic time solutions and are pulling this shit instead. Simple embarrassing.
Leap seconds are stupid in my opinion. Under no circumstances should a timescale have discontinuities like that.
If true, oooooh goooood! I agree with big tech on this one.
Redefine the UTC starting point at the last 17th update and be done with it.
"Facebook developers are apparently so frightened of a negative leap second that they think altering the way global timekeeping works is easier than fixing their code"
Dropping any new leap seconds is choosing not to break a million systems, irregularly, to no purpose. No code needs to change. Things just stop breaking.
It’s akin to saying I want 2+2=5 because my code happens to work that way and it’s hard to fix.
If FB hates leap seconds so much they can switch to TAI or Unix Epoch time. It’s not like UTC was modified to add leap seconds. It’s always been like that. It should not have come to them as a surprise.
Converting to UTC is easy when you need it.
Meta's suggestion just shows how narrow-minded they are.
As I hinted, I'm sufficiently experienced with precise timestamping to know that TAI is the proper way there, and that "improving" UTC is not going to help. Their suggestion is that UTC should essentially be the same as TAI because there is code that makes incorrect assumptions about what UTC is. If you need a monotonic clock, there is already something for that. UTC is for the actual local time on Earth.
I suggest they don’t then them back on. Eventually a startup who can deal with either TAI or leap seconds will take their place.
You could simply be working on a single computer and have to deal with time issues. (E.g. Local clock resetting to a prior date and system creating files timestamped earlier than older files.)
I think the leap second is the most minor, not even worth mentioning problem. It is actually to our benefit, reminding us that (perceived) UTC is not a monotonic measure and computer time altogether is not. Computers nowadays adjust their time ~constantly.
That they have to smear their leap second throughout multiple hours, and that computers having the wrong time leads to an outage (for a less than a second difference) troubles me honestly. What you are telling me is that next leap second we should all pray for Meta's NTP servers not going down???
Also: (if you are an fb engineer) What do you do with negative leap seconds? Speed things up...? (https://www.timeanddate.com/time/negative-leap-second.html) The expectation is for a negative leap second coming up -- as the post does mention.
This is an education problem if you expect that time intervals have to be strictly positive (or jump ahead). TL;DR: systems' should never use the wall clock to compute a time interval even if we get rid of leap seconds.
No, in today's world time is a programmers' problem. Nobody except programmers (and some very technical software product managers, e.g. astronomers) needs to deal with time issues like these.
Who builds systems that need to be synchronized to the microsecond level or more? Programmers. Who makes calendar software that should support timezones and DST correctly? Programmers. Who runs astronomy calculations that really care about UT1? Programmers working for astronomers.
Every time someone has an issue that requires very delicate handling of time, there is a programmer implementing the solution.
So of course it would be a group of the largest software companies, responsible for software like Outlook and GCal and public clouds, who would get together to say "listen, world, this leap second thing is more trouble than it's worth, how about we just stop fiddling with it?" They're the people responsible for implementing everyone else's time handling requirements. I think we should listen to them.
Another confusing argument here is "let them just move from UTC to TAI, and thus move leap seconds to be a display issue, like timezone best practice".
In a vacuum, this could have been a great solution. But we live in a world where almost all computer software already written is based on UNIX Epoch Time, which is defined as tweakable by the leap second committee, and the breakage usually occurs either in existing software or in sync issues between new software written at Meta or MS or wherever and existing software, so moving all their centrally managed systems to TAI while leaving us programmers of the less hierarchical outside world to keep suffering wouldn't solve much, and also wouldn't be very nice.
Kind of an https://xkcd.com/927 situation.
Instead, they're writing a letter saying "dear leap second committee, we are your largest users and our use case is representative of everyone else's, can you please stop fiddling with the standard agreed time, it's causing problems for everyone. You can get the same effect by twiddling with display time (timezones), which we already have to support anyway and is much easier to test."
My favorite design principle is the Representable/Valid principle: your representation/model of the world should have one way to represent each valid state, and should not have ways to represent invalid states. Lets get together as a species and refactor our model of time to have one less case of two states having the same representation!
I for one welcome our new monotonic timelords.