> ... 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.
Leap seconds have so many problems beyond the time adjustment. It's a small/odd enough adjustment interval that there are wildly different approaches like leap smears. On top of being so small, it's rare enough (~every 2 years), depending on how a system is used, lack of proper handling might not be obviously apparent or lack of obvious problem in one implementation ignoring it may lead to lack of care in another implementation which would have a problem ignoring it.
Leap hour replaces all of that with what is more or less equivalent to a change in DST rules (except for more time zones at once). DST changes don't go perfect either by any means... but we do them regularly enough without the world crashing down that doing an additional shift change of an extra hour every 5000 years is almost certainly less hassle and breakage than the leap second approach breaking things every ~2 years.
IMHO the correct way to handle leap seconds would have been at the same layer as timezones, i.e. a display-only thing. Timezone databases are regularly updated, you push out leap second updates there. In the worst case, people's clocks are off by one second but all the underlying timing logic doesn't crash.
The calendar adjustments are because the planet's constant orbital period isn't a whole number of days.
The leap seconds were an attempt to have wall clock time map to the planet's rotational angle consistently despite the problem that the planet's spin varies unpredictably.
Yes the "leap hour" is a legal fiction of course. In reality in the event anybody cares about this in the distant future they will make the kind of "drastic" changes you've probably experienced twice a year for your whole life and barely noticed... More likely because the drift is so incredibly slow they won't change anything.
> One 'answer' to this concern is to have a 'leap hour' or something in the future (some future generation's problem, not ours)
A simpler solution: we already have an offset between local time and coordinated time, just change that offset. So, for instance, Brasília Time, which is currently UTC-03, would become UTC-02 or UTC-04, depending on which way the change went.
> 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
“Over time” really glosses over how much time it would take. In 500 years there might be half as much divergence between solar noon and 12:00pm as we intentionally inflict on ourselves with DST, or that France and Spain inflicted on themselves in the 1940’s so they could share a time zone with Germany. By the time anyone will even notice we will probably change time systems for other reasons anyway. It’s not even remotely comparable to the Julian/Gregorian issue, which dealt with leap days. Each day has 86400 seconds.
>There is some talk of eliminating the leap second
The concern, of course, is that some universes eliminating them while others don't can puts us out of sync. This creates a wobble that could potentially throw us out of Hilbert space.
> 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.
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.
> 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.
<rant> It won't happen on a human scale. So why oh why do we screw around with this moronic leap-second nonsense ? Oh dear, in the year 4000 noon will arrive three minutes earlier compared to now. So? </rant>
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.
Yes I would assume that the NTP daemon would handle a leap second arrival with guarantees of (1) gradual application over a longer period and (2) never moving the clock backwards, only slowing it a little.
I wonder if all NTP implementations don't follow those guarantees?
Oh and another app that hates clock jumps used to be sshd; it would just bail out and drop all connections. We found that out while chasing ANOTHER bug in SunOS on a T4: they didn't have it mutexed right so it possible to read its RTC register while it was in the middle of getting updated so the client would read a garbage time. We chased NTP for a week before realizing it was the kernel.
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.
I remember that well (because my manager at the time was asking me afterwards "why were you up at 2 in the morning restarting services?" and didn't believe my answer :( )
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.
We convert timestamps to and from date+times all the time. Having each day be exactly 86400 seconds simplifies this a lot, and practically every app benefits from that. Leap second smearing will ensure smooth and continious time.
Taking leap seconds into account is only needed in a very, very few contexts - maybe astronomy, or certain kinds of high-speed physics? Those rare users should be able to figure stuff out.
Go with UTC, don't optimize for rare usecases at the expense of everyone else.
Your message contradicts itself.
Firstly it says leap seconds should not be used (aka TAI). But at the last sentence it says "go with UTC" (which has leap seconds).
>Having each day be exactly 86400 seconds simplifies this a lot, and practically every app benefits from that.
Making an assumption that a day 86400 seconds breaks at least twice a year in many parts of the world, and that's before we introduce leap seconds or possibility of your code running on hardware that itself travels across timezones.
You clearly do not know how much havoc and complexity leap seconds introduce into various systems. This is why leap seconds are likely to be phased-out [0]. It's effectively an admission that use of leap seconds in the "base" time was a mistake.
>We convert timestamps to and from date+times all the time.
If you do not account for time zones during this conversion, then you are not qualified to implement such conversions.
It's fine to use 86400 seconds for durations (e.g. "this computation will finish in 1d 8h 20m 34s"), but it's absolutely not fine to use it while dealing with datetimes.
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.
> This way I know that 14:00 today + one month is still 14:00 in my "internal" time format
Unless there's a leap second in that month. Then it would be 13:59. Maybe you don't care, but some people do. It could have legal or technical ramifications.
> 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).
What do you mean by month? Calendar months are obviously irregular (thanks February). "30 days" makes perfect sense in TAI. Indeed, 14:00 today + 30 days would always be 14:00 in TAI.
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.
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.
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].
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.
Wow that's really interesting. A great quote form the article:
> In 2021, it was reported that Earth was spinning faster in 2020 and experienced the 28 shortest days since 1960, each of which lasted less than 86399.999 seconds.[24] This caused engineers worldwide to discuss a negative leap second and other possible timekeeping measures, some of which could eliminate leap seconds.[25] The shortest day ever recorded was 29 June 2022, at 1.59 milliseconds less than 24 hours.[26] In a 2024 paper published in Nature, Duncan Agnew of the Scripps Institution of Oceanography projects that the water from increasing ice cap melting will migrate to the equator and thus cause the rate of rotation to slow down again.[26]
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)
I'd argue the opposite is true for anyone who has studied statistics which is largely built on Instrumentalism (think George Box: 'All models are wrong, but some are useful') and Popperian falsification (Null Hypothesis testing). We are absolutely taught to treat models as predictive tools rather than metaphysical truths.
A distinction without a difference. The only way we can interact with the world is via senses, via instruments, via measurement. We can rehash solipsism, but seeing as how that is an immediate dead end we all agree there is a physical reality. If there is in fact a reality, then we are measuring something real.
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.
Hmm. I understand that perspective, but I'm not sure I agree. It does seem to matter over a relatively short & realistic time scale. According to the Wikipedia page, there have been 27 seconds added since 1972, which is only 44 years ago. At that rate, that's about 1 minute per 100 years. We have many systems that have existed for several centuries and I think it's not unreasonable to start making plans for systems that may exist for millennia, where you're starting to talk about a 10+ minute offset at the current rate.
But I do think there is a valid argument that the infrequency of these events cause more issues than maybe one large adjustment 500 years from now would cause. Not sure where I land on this one.
The problem is that Earth's rotation isn't consistently faster. Some years leap seconds need to be added, some years they need to be removed. Would be far better to leave them alone, let them average out, and as the GP said let the people who care about this add the offset they need.
You make a good argument for the opposite of your conclusion. If you’re planning a system that’s supposed to last for millennia, that system shouldn’t depend on the fiat of the International Earth Rotation and Reference Systems Service.
Let's just do leap minutes. If humanity survives long enough to witness a leap minute without destroying ourselves then that's ample compensation for the minor inconvenience.
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.
Before modern standardization, maintaining calendars and clocks was typically the responsibility of states or similar authorities, often guided by astronomers. Now it seems that international organizations are effectively following the early UNIX/POSIX model, and astronomers no longer have the same authority over timekeeping.
Unless you want to abolish timezones entirely, which would simplify clocks but complicate a whole lot else in society, you're going to need leap-something. Would leap minutes or hours really be much better? The idea that doing things less often causes more problems is a reasonable one.
In the 56 years since UTC was established, there have only been 37 leap seconds. At that rate it would take more than 5400 years before it would affect solar noon more than DST does. I'm more than okay kicking the can that far down the road in the name of avoiding all the ridiculous solutions that are needed to accommodate leap seconds. We've endured these headaches to potentially solve a problem for people who might not even still be using UTC.
Compare that to removing the leap day, where the start of seasons would be noticeably affected within just a few decades. Hundreds of years ago, a pretty insignificant headache was invented which is providing constant payoffs.
We need to do "leap hours" anyway--just today they changed to daylight saving time in the U.S.! And time zones are also adjusted every now and then, which also amounts to a one-hour change in the affected regions. Even if we didn't have continous practice with leap seconds, I think we could definitely include an extra one-hour shift for earth rotation reasons along with all the other ones.
Which means that time changes slowly enough that we don't notice. At some point everybody goes work half an hour earlier because it makes sense. Schools start earlier, shops open earlier. It doesn't have to be coordinated worldwide. Every region or even town can have its own customs. Then people notice they are in the wrong time zone and a country moves to a different time zone.
Statistically, nobody on Earth knows what UTC is. People know about their local time zone and how it related to time zones in other countries. Where the position of the sun is relative to UTC, almost nobody knows.
Yet high noon at my current location comes at 12:03 (1:03 with DST). It's three minutes off. If I lived further west in my timezone, noon would come much
later.
How can people manage with noon off by minutes, yet want leap-second accuracy every 6 months?
Readit News
> ... 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.
We've had 27 leapseconds in the last 54 years [1] - an average of 0.5 seconds per year.
At that rate, solar time will drift by 60 seconds over the course of 120 years. Drifting by 10 minutes will take 1200 years.
The leap hour will be in 7200 years, around year 9226.
[1] https://en.wikipedia.org/wiki/Leap_second
Leap hour replaces all of that with what is more or less equivalent to a change in DST rules (except for more time zones at once). DST changes don't go perfect either by any means... but we do them regularly enough without the world crashing down that doing an additional shift change of an extra hour every 5000 years is almost certainly less hassle and breakage than the leap second approach breaking things every ~2 years.
The leap seconds were an attempt to have wall clock time map to the planet's rotational angle consistently despite the problem that the planet's spin varies unpredictably.
Yes the "leap hour" is a legal fiction of course. In reality in the event anybody cares about this in the distant future they will make the kind of "drastic" changes you've probably experienced twice a year for your whole life and barely noticed... More likely because the drift is so incredibly slow they won't change anything.
A simpler solution: we already have an offset between local time and coordinated time, just change that offset. So, for instance, Brasília Time, which is currently UTC-03, would become UTC-02 or UTC-04, depending on which way the change went.
“Over time” really glosses over how much time it would take. In 500 years there might be half as much divergence between solar noon and 12:00pm as we intentionally inflict on ourselves with DST, or that France and Spain inflicted on themselves in the 1940’s so they could share a time zone with Germany. By the time anyone will even notice we will probably change time systems for other reasons anyway. It’s not even remotely comparable to the Julian/Gregorian issue, which dealt with leap days. Each day has 86400 seconds.
The concern, of course, is that some universes eliminating them while others don't can puts us out of sync. This creates a wobble that could potentially throw us out of Hilbert space.
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.
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.
Deleted Comment
<rant> It won't happen on a human scale. So why oh why do we screw around with this moronic leap-second nonsense ? Oh dear, in the year 4000 noon will arrive three minutes earlier compared to now. So? </rant>
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.
I wonder if all NTP implementations don't follow those guarantees?
Oh and another app that hates clock jumps used to be sshd; it would just bail out and drop all connections. We found that out while chasing ANOTHER bug in SunOS on a T4: they didn't have it mutexed right so it possible to read its RTC register while it was in the middle of getting updated so the client would read a garbage time. We chased NTP for a week before realizing it was the kernel.
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?"
[0]: https://en.wikipedia.org/wiki/International_Atomic_Time
We convert timestamps to and from date+times all the time. Having each day be exactly 86400 seconds simplifies this a lot, and practically every app benefits from that. Leap second smearing will ensure smooth and continious time.
Taking leap seconds into account is only needed in a very, very few contexts - maybe astronomy, or certain kinds of high-speed physics? Those rare users should be able to figure stuff out.
Go with UTC, don't optimize for rare usecases at the expense of everyone else.
Making an assumption that a day 86400 seconds breaks at least twice a year in many parts of the world, and that's before we introduce leap seconds or possibility of your code running on hardware that itself travels across timezones.
>We convert timestamps to and from date+times all the time.
If you do not account for time zones during this conversion, then you are not qualified to implement such conversions.
It's fine to use 86400 seconds for durations (e.g. "this computation will finish in 1d 8h 20m 34s"), but it's absolutely not fine to use it while dealing with datetimes.
[0]: https://en.wikipedia.org/wiki/Leap_second#Phase-out_and_futu...
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.
Unless there's a leap second in that month. Then it would be 13:59. Maybe you don't care, but some people do. It could have legal or technical ramifications.
> 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).
What do you mean by month? Calendar months are obviously irregular (thanks February). "30 days" makes perfect sense in TAI. Indeed, 14:00 today + 30 days would always be 14:00 in TAI.
https://developers.google.com/time/smear
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.
Deleted Comment
[0]: https://en.wikipedia.org/wiki/Leap_second
I have read numerous explanations, but haven't found a really authoritative discussion.
[0] https://en.wikipedia.org/wiki/Leap_second#Rationale
> In 2021, it was reported that Earth was spinning faster in 2020 and experienced the 28 shortest days since 1960, each of which lasted less than 86399.999 seconds.[24] This caused engineers worldwide to discuss a negative leap second and other possible timekeeping measures, some of which could eliminate leap seconds.[25] The shortest day ever recorded was 29 June 2022, at 1.59 milliseconds less than 24 hours.[26] In a 2024 paper published in Nature, Duncan Agnew of the Scripps Institution of Oceanography projects that the water from increasing ice cap melting will migrate to the equator and thus cause the rate of rotation to slow down again.[26]
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'd argue the opposite is true for anyone who has studied statistics which is largely built on Instrumentalism (think George Box: 'All models are wrong, but some are useful') and Popperian falsification (Null Hypothesis testing). We are absolutely taught to treat models as predictive tools rather than metaphysical truths.
I can see how someone could misunderstand or forget what they're taught though.
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.
But I do think there is a valid argument that the infrequency of these events cause more issues than maybe one large adjustment 500 years from now would cause. Not sure where I land on this one.
Thanks for making me a decade younger :)
For 99% of the world today, high noon =/= 12:00:00. Nothing breaks because of this. The world continues to run.
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...
Before modern standardization, maintaining calendars and clocks was typically the responsibility of states or similar authorities, often guided by astronomers. Now it seems that international organizations are effectively following the early UNIX/POSIX model, and astronomers no longer have the same authority over timekeeping.
Compare that to removing the leap day, where the start of seasons would be noticeably affected within just a few decades. Hundreds of years ago, a pretty insignificant headache was invented which is providing constant payoffs.
And anyone that cares about the relationship of the time of day and the position of the Sun.
Granted, it's not a lot, only a minute per century.
Statistically, nobody on Earth knows what UTC is. People know about their local time zone and how it related to time zones in other countries. Where the position of the sun is relative to UTC, almost nobody knows.
How can people manage with noon off by minutes, yet want leap-second accuracy every 6 months?
Deleted Comment