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.
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.
* https://www.scientificamerican.com/article/leap-seconds-may-...
* https://scripps.ucsd.edu/news/global-warming-influencing-glo...
The general trend is slowing down. Apparently (?) once the day gets to be 24h+0.001sec (+1 millisecond), a leap second would occur about every 1000 days; then when it becomes 24h+0.002sec, a leap second would occur about every 500 days; when it reaches 24h+0.003sec, a leap second would occur about every year; etc.
I'm a fan but it's rare for anyone else to agree!
As you say, what the computer should maintain internally and for communication with other computers, not with humans, is only true time and not other quantities, like the angles between Earth, Sun and stars.
Only TAI is true time, while "universal time" is an angle and "universal time coordinated" (UTC) and its derivatives are some weird hybrid quantities that can be computed from times and angles.
The conversions between true time and various kinds of official times used by humans are very complex and they should be handled in a single place, not in various places that may handle time zones and discrepancies between UTC and TAI and various other "times", e.g. UT2, UT1 etc.
Prescheduled.
Now tell everyone we're having one June 30, 2029, and see how things go.
Which is about how long it took for folks to switch from the Julian to the Gregorian calendar.
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.
“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.
<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>
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.
7200 years ago the Neolithic revolution was still in full swing and many of the most famous megaliths like Stonehenge hadn’t even been built yet. The first real state, the Sumerian civilization, hadn’t formed yet in Mesopotamia.
Personally, I’m very comfortable making this someone else’s problems 7200 years from now. If they’re still having basic coordination issues then it’s their own damn problem.
Older folks at Göbekli Tepe grumbled that climate change wasn't real. As far as they were concerned, the Sumer and Indus Valley kids were playing with fire and didn't know squat. The older generation just couldn't understand the crazy architecture over in Egypt and the slangy "new wave" movement at Salisbury Plain. It always seemed that the shiftless youth there just loitered and smoked and invented new expressions to frustrate communication. And everyone could agree that no one liked their so-called music!
https://en.wikipedia.org/wiki/G%C3%B6bekli_Tepe
https://en.wikipedia.org/wiki/8.2-kiloyear_event
https://en.wikipedia.org/wiki/Sumer
https://en.wikipedia.org/wiki/Indus_Valley_Civilisation
The dinosaurs had days with fewer hours than us.
Now we have locked in second extremely hard underpinning all of our measurements. But you could consider that you have same number of hours in a day and length of those hours has changed...
You mean 09226, I believe. [1]
[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
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.
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.
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 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.
From the time of Julius Caesar to 325 AD, more than 3 days of drift had accumulated, so the Gregorian calendar would have required 13 or 14 days of correction.
When many countries transitioned to the Gregorian calendar much later, they had to add additional correction days to the initial 10-day difference, about 1 day per century.
That is false. See https://kiwihellenist.blogspot.com/2022/05/julian-calendar.h... , or "Digression #2: why do Roman writers report the date of the solstice as 25 December?" at https://kiwihellenist.blogspot.com/2015/12/christmas-and-its... .
Solstices were on the 25th a few hundred years before the time of Julius Caesar. He did not even attempt to put them back there.
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.
It's not like we wound back by 24 hours on leap days, that would be insanity. So in addition of leapseconds being a rare problem, it's also handled in a uniquely bad way.
This makes sense for timestamps in traditional logs. You don't have to second guess the order of things, especially across multiple systems or services.
I know we just get a 60th second in a minute. What unix and NTP timestamps do (or originally did) was repeating a second. Then we got other hacks to keep monotonicity, like smearing. Not without tradeoffs.
(I regret I did not put in the research prior to answering to your comment: https://www.meinbergglobal.com/english/info/leap-second.htm#... )
> ... 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.