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