Interesting! There's a lot I don't know about this, but I know a little more now. I'll admit, I naively thought this would be more regular than it appears to be [0].
They teach us Scientific Realism in school, but reality is that we are really using Instrumentalism.
That said, no one wants to admit it, so contemporary science follows Falsification, where we find ways to not actually make claims about reality. (Which as an Instrumentalist/pragmatist, I love Karl Popper, its just not metaphysical truth. And that would break Popper's heart)
The Earth is generally expected to spin more slowly over time, due to tidal friction. But it has been spinning faster and faster since the 1960s. As shown in the figure in the wikipedia article [0].
I have read numerous explanations, but haven't found a really authoritative discussion.
> ... the "invisible infrastructure" of the web; balancing historical accuracy with the technical need to minimize zone fragmentation is a much more complex trade-off than it appears on the surface ...
The complexity goes up tremendously if some condition is rarely encountered: eg leap second. This means it gets pushed to a "corner case" and tested more lightly and more rarely.
At $work around 2014 we had three different hardware GPS types which we used for precision timekeeping; some chips, daughterboards, and firmware. One day a leap second arrived -- it gets broadcast to aGPS hardware a day ahead of time -- and all three implementations handled it differently. One handled it, one did something else like ignore it, and I think one even bricked itself. That situation was less than bueno.
> The complexity goes up tremendously if some condition is rarely encountered: eg leap second. This means it gets pushed to a "corner case" and tested more lightly and more rarely.
There is some talk of eliminating the leap second, which would over time have the Earth and sun diverge with regards to noon and such. One 'answer' to this concern is to have a 'leap hour' or something in the future (some future generation's problem, not ours): but given that people can't even get February 29th correct now, and it happens regularly, I don't see how a one-off event would be made to work. It'd be a huge coördination problem.
Just look at the introduction of the Gregorian calendar: it was slightly off since the time of Julius Caesar, but that minor error added up over time, to the point that to get the equinoxes/solstices back to where they 'should' be 10 days had to be removed with the Gregorian calendar. And because of politics (or a religious flavour) it took a long while for everyone to get on the same page.
Unfortunately, the Gregorian calendar has not restored the time of Julius Caesar, but the time of the First Council of Nicaea (325 AD), when the rule about how to compute the date of the Easter was established.
For the time of Julius Caesar, about 3 more days would have been needed, which would have made the Christmas coincident with the Winter Solstice, and which would have made much more sense.
> to the point that to get the equinoxes/solstices back to where they 'should' be 10 days had to be removed with the Gregorian calendar
Note that the equinoxes and solstices are officially supposed to be on the 25th. By the time of Julius Caesar, that had diverged, but the divergence in reality made no impact on the date of the official solstice. The Gregorian calendar could easily have put the solstices back on the 25th, but chose not to.
The last leap-second I encountered (also the 2014 one) crashed my MySQL databases.
you wouldn't assume that it depends on time like that, because honestly why would it? "surely it's fine, NTP corrects drift of a second fairly frequently"- but a leap second is not a drift, it's something quite insane unless your primitives are solid. Nobody would test for this.
Leap Seconds need to be abolished. The only people who need it are Astronomers. They could just use an offset. Implementing leap seconds correctly is a huge burden, for no gain.
Where I live, high noon today occurs at 1:03 PM. No one is complaining that it is 3 minutes (or 63 minutes) off. It's a non-issue for 99.9% of the population.
Astronomers do not need leap seconds, because even with this adjustment UTC cannot be used to determine anything in astronomy.
Astronomers need either true time, which is TAI, to be used in computing the positions of celestial bodies, and they need for observations the so-called Sidereal Time, which is not a time but the angle between a coordinate system attached to the Earth and an inertial system of coordinates attached to distant celestial objects that have negligible angular movement (in the past those were distant stars, now they are distant galaxies or quasars).
The Sidereal Time can be computed in a complex way from TAI, because it is determined by the periodic rotation and precession of the Earth and by various superposed periodic or random movements.
The UTC is not adjusted to match the current true rotation angle of the Earth, which you can measure by looking up to the stars, but it is adjusted to match within 1 second a fictitious angle that would be the rotation angle of the Earth-Sun direction corresponding to an Earth that would rotate uniformly both around itself and around the Sun, so that the duration of a day would have been constant.
In reality, the duration of a Solar day, i.e. the time between 2 consecutive noons, varies a lot during the year, by a large fraction of an hour (by about a half of hour peak-to-peak), so using UTC directly for estimating the position of the Sun gives a very big error, of many minutes of hour.
So what you need for astronomy is to know the current TAI and you need a Sidereal Time calculator, which you need for knowing in what direction to point your telescope, to find a given celestial object.
UTC cannot be used directly in astronomy, but only after passing either explicitly or implicitly through TAI. The fact that astronomical almanacs are published using UTC in their tables is obfuscating this, because the values in the tables have not been computed using UTC, but everything has been converted to UTC to match the time that is presumably shown by the watch or clock that the almanac user may have.
How about a leap minute instead so we only have to worry about this when it's not a problem anymore :)? We will either hit the fermi filter or accend intelligence.
We should just have a standards body that meets each decade and decides what epoch time every day for the next 10 years officially starts on. Everyone knows ahead of time how it will work, software updates have predictable change intervals, it allows us to refresh time based on policy decisions, and it uses something sane as the backbone of the system.
Back in the early 2010s my company was maintaining a Spring application processing ActiveMQ messages. We'd received word that the application wasn't processing work. One of us goes and looks at logs and sees just endless volumes of stack traces. Eventually the suggestion is made and accepted to just reboot the application. That fixed it.
Turns out the JVM simply lost its mind when leap seconds were introduced. So, for the next several years, we watched that French society's website that announced when leap seconds would be introduced and scheduled application restarts accordingly.
Google and lots of other firms use a "leap smear" to hide the leap second from end users, essentially "smearing" the second across the hours before and after each leap.
Computer systems (most importantly, UNIX) should've been using TAI [0] from the beginning. Human-readable time in turn should be computed from it using periodically updated time zones database which would include offset between TAI and UTC. By eliminating leap seconds we effectively re-invented TAI with a weird offset. While I am in favor of eliminating leap seconds as a hacky way to fix the current mess, it's sad to see that we added yet another quirk to the already complicated system of datetime keeping.
Huh, that's an interesting point. Not sure I agree though. I always was irritated by the complaint that leap seconds are complicated and must be eliminated, and I am convinced that eliminating them in UTC is the most idiotic decision ever made, and I sincerely hate the idiots who made it, but, indeed, the idea that UTC time is just a time-zone representation of linear TAI time on Earth does make a lot of sense. On the other hand, we still can convert between UTC and TAI, so treating TAI as primary only makes sense if it clearly would make things simpler. And it's very unclear if it would. It really seems like the "correct" abstraction, but the problem is that currently my main hack for avoiding time complexity is always using datetimes in UTC+0 internally, thus ignoring time zones until I need to display something for user. This way I know that 14:00 today + one month is still 14:00 in my "internal" time format, even if in the user TZ one is DST and the other one is not. And a hundred of other ugly things I am willing to ignore in practice. And in 99.999% of cases I don't even care how many days are in that month, let alone seconds.
Now, if I cannot really add a month anymore (and I cannot in TAI, because months don't even really exist in TAI, since TAI isn't a solar year) in my internal time format, all that convenience goes away. I now must always worry about leap seconds and timezones and all the stuff I don't really need to think about in the vast majority of cases.
…Yeah, well, I'm really not sure. I am not convinced, and am honestly kinda relieved by the fact I won't have to find out. But it's an interesting point nevertheless. And, no, UTC w/o leap seconds is not the same thing. In fact, UTC w/o leap seconds is kinda the polar opposite: it's clearly the wrong abstraction, because it ignores the (not even so hard) problem somebody doesn't want to deal with, which doesn't really go away, but is very practical.
The idea that if being dark at 12pm in 20k years will bother anyone is absurd. The shift will happen so slowly that the only people who will even realize it happened are historians and history buffs.
Really the idea that there will enough civilizational continuity that our current timekeeping infrastructure and systems will continue unbroken for that long is insane.
We're still using a calendar that was essentially created by Julius Caesar (with a slight adjustment by Pope Gregory). I think you're underestimating the power of continuity.
The worst bug I ever dealt with in a 20 year career was a leap second bug (back in 2012). Servers all slowed down dramatically very suddenly, CPU saturated. No relevant code changes or changes in traffic. Turns out, they just got into that state due to a leap second. Some Livelock bug.
A restart fixed everything.
It wasn't just our site that went down. If I recall correctly, many other large sites (like Reddit, LinkedIn, etc) also had the same issue. Guess no one thought of the "did you try restarting it?"
Me too! In my case postfix locked up and stopped sending mail there was a massive queue. I checked the logs and saw the same second twice and that's when I learned about leap seconds. Since then I have a reminder in my calendar every 6 months to check if ones been announced. Thankfully we've only had two.
33 comments
[ 2.4 ms ] story [ 64.0 ms ] thread[0]: https://en.wikipedia.org/wiki/Leap_second
That said, no one wants to admit it, so contemporary science follows Falsification, where we find ways to not actually make claims about reality. (Which as an Instrumentalist/pragmatist, I love Karl Popper, its just not metaphysical truth. And that would break Popper's heart)
I have read numerous explanations, but haven't found a really authoritative discussion.
[0] https://en.wikipedia.org/wiki/Leap_second#Rationale
> ... the "invisible infrastructure" of the web; balancing historical accuracy with the technical need to minimize zone fragmentation is a much more complex trade-off than it appears on the surface ...
The complexity goes up tremendously if some condition is rarely encountered: eg leap second. This means it gets pushed to a "corner case" and tested more lightly and more rarely.
At $work around 2014 we had three different hardware GPS types which we used for precision timekeeping; some chips, daughterboards, and firmware. One day a leap second arrived -- it gets broadcast to aGPS hardware a day ahead of time -- and all three implementations handled it differently. One handled it, one did something else like ignore it, and I think one even bricked itself. That situation was less than bueno.
There is some talk of eliminating the leap second, which would over time have the Earth and sun diverge with regards to noon and such. One 'answer' to this concern is to have a 'leap hour' or something in the future (some future generation's problem, not ours): but given that people can't even get February 29th correct now, and it happens regularly, I don't see how a one-off event would be made to work. It'd be a huge coördination problem.
Just look at the introduction of the Gregorian calendar: it was slightly off since the time of Julius Caesar, but that minor error added up over time, to the point that to get the equinoxes/solstices back to where they 'should' be 10 days had to be removed with the Gregorian calendar. And because of politics (or a religious flavour) it took a long while for everyone to get on the same page.
For the time of Julius Caesar, about 3 more days would have been needed, which would have made the Christmas coincident with the Winter Solstice, and which would have made much more sense.
Note that the equinoxes and solstices are officially supposed to be on the 25th. By the time of Julius Caesar, that had diverged, but the divergence in reality made no impact on the date of the official solstice. The Gregorian calendar could easily have put the solstices back on the 25th, but chose not to.
The last leap-second I encountered (also the 2014 one) crashed my MySQL databases.
you wouldn't assume that it depends on time like that, because honestly why would it? "surely it's fine, NTP corrects drift of a second fairly frequently"- but a leap second is not a drift, it's something quite insane unless your primitives are solid. Nobody would test for this.
* https://www.npr.org/2024/03/30/1241674216/climate-change-tim...
† T23:59:58Z would have skipped/suppressed :59 and gone to T00:00:00Z.
Where I live, high noon today occurs at 1:03 PM. No one is complaining that it is 3 minutes (or 63 minutes) off. It's a non-issue for 99.9% of the population.
Astronomers need either true time, which is TAI, to be used in computing the positions of celestial bodies, and they need for observations the so-called Sidereal Time, which is not a time but the angle between a coordinate system attached to the Earth and an inertial system of coordinates attached to distant celestial objects that have negligible angular movement (in the past those were distant stars, now they are distant galaxies or quasars).
The Sidereal Time can be computed in a complex way from TAI, because it is determined by the periodic rotation and precession of the Earth and by various superposed periodic or random movements.
The UTC is not adjusted to match the current true rotation angle of the Earth, which you can measure by looking up to the stars, but it is adjusted to match within 1 second a fictitious angle that would be the rotation angle of the Earth-Sun direction corresponding to an Earth that would rotate uniformly both around itself and around the Sun, so that the duration of a day would have been constant.
In reality, the duration of a Solar day, i.e. the time between 2 consecutive noons, varies a lot during the year, by a large fraction of an hour (by about a half of hour peak-to-peak), so using UTC directly for estimating the position of the Sun gives a very big error, of many minutes of hour.
So what you need for astronomy is to know the current TAI and you need a Sidereal Time calculator, which you need for knowing in what direction to point your telescope, to find a given celestial object.
UTC cannot be used directly in astronomy, but only after passing either explicitly or implicitly through TAI. The fact that astronomical almanacs are published using UTC in their tables is obfuscating this, because the values in the tables have not been computed using UTC, but everything has been converted to UTC to match the time that is presumably shown by the watch or clock that the almanac user may have.
https://rin.org.uk/news/624222/Leap-Seconds-To-Be-Phased-Out...
Turns out the JVM simply lost its mind when leap seconds were introduced. So, for the next several years, we watched that French society's website that announced when leap seconds would be introduced and scheduled application restarts accordingly.
https://developers.google.com/time/smear
[0]: https://en.wikipedia.org/wiki/International_Atomic_Time
Now, if I cannot really add a month anymore (and I cannot in TAI, because months don't even really exist in TAI, since TAI isn't a solar year) in my internal time format, all that convenience goes away. I now must always worry about leap seconds and timezones and all the stuff I don't really need to think about in the vast majority of cases.
…Yeah, well, I'm really not sure. I am not convinced, and am honestly kinda relieved by the fact I won't have to find out. But it's an interesting point nevertheless. And, no, UTC w/o leap seconds is not the same thing. In fact, UTC w/o leap seconds is kinda the polar opposite: it's clearly the wrong abstraction, because it ignores the (not even so hard) problem somebody doesn't want to deal with, which doesn't really go away, but is very practical.
Really the idea that there will enough civilizational continuity that our current timekeeping infrastructure and systems will continue unbroken for that long is insane.
A restart fixed everything.
It wasn't just our site that went down. If I recall correctly, many other large sites (like Reddit, LinkedIn, etc) also had the same issue. Guess no one thought of the "did you try restarting it?"
https://qntm.org/leap