hckrnws
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?"
Yep, I was there too! HN thread from the time: https://news.ycombinator.com/item?id=4188412
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 :( )
Responding to a deleted comment:
> ... 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.
> One 'answer' to this concern is to have a 'leap hour' or something in the future
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.
> 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.
"And so the Y10K problem was born"
I just had a Y10K problem. Customer data was using 9999-12-31 23:59:59 as a placeholder value, and our app crashed converting from the customer's timezone to UTC. I learned that Python datetime can't handle Y10K.
I’d better go brush up on my COBOL
Programmer-Archaeologist will be quite a coveted position 300 gigaseconds from now.
"Basic" made me lol :)
You're missing that the frequency of leap seconds is accelerating over time, because Earth's rotation is slowing down. The leap hour will therefore happen earlier: https://www.ucolick.org/~sla/leapsecs/future2100.svg
Yeah. There’s also the issue that the earth’s rotation is slowing down, so over the long term leap seconds would become more and more frequent. There’s a point when the earth is slow enough that leap seconds need to happen nearly every month, and by that point they are no longer a workable solution to the problem. That is expected to take a few thousand years, comparable to the point where a leap hour would be needed if there were no leap seconds.
So some future generations might get 23 hour days? That’s gonna be an interesting problem to solve for calendar implementations
As another poster already said, there will be 25-hour days at some time.
The dinosaurs had days with fewer hours than us.
Where there fewer hours or were those hours just different length?
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...
25-hour days.
> The leap hour will be in 7200 years, around year 9226
You mean 09226, I believe. [1]
[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
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.
It is way more easy to let UTC (without leap seconds) just drift away from the zero meridian and move countries to different time zones when convenient. We mess around with daylight savings time often enough that nobody will notice if we have change local time every couple of thousand years.
DST changes are pre-scheduled. Throwing a random hour in/out at (say) June 30, 2029 may be something else. Unless the jump is treated as a TZ change in tzdata?
Yeah you treat it as a time zone change where every zone moves over (or every country moves to the adjacent zone maybe). You can schedule it N years in advance. It's definitely not 0 disruption, but it's very manageable. Regions change TZs or toggle DST frequently enough that we can handle it.
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.
So lunar tidal forces are slowing the rotation, but (recently?) Earth mantle/core is causing a speed up, but climate change and melting ice is contributing to the slow down side:
* 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.
Comment was deleted :(
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.
you can use TAI (international atomic time, basically UTC without leap seconds) if you want to be serious about it
I'm a fan but it's rare for anyone else to agree!
The problem with TAI is that the rest of the world uses UTC. So you can use TAI on a small island and then you have to convert to and from UTC. My hobby kernel is based on TAI internally. And it constantly converts to and from UTC.
You do not use TAI to communicate with the rest of the world, except for certain special purposes.
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.
I fully expect in such a regime, people would be complaining about how the leap second insertion caused their recurring meeting to shift from 9am to 8:59:59
In British Colombia they’re locking into daylight savings time, so I think it’s safe to say that people aren’t really bothered by solar accuracy.
> 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.
> 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.
By the time of Julius Caesar, the solstices were on the 25th, which is the reason why Christmas is celebrated on that day.
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.
>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.
[dead]
Comment was deleted :(
We had a leap hour yesterday...
> We had a leap hour yesterday...
Prescheduled.
Now tell everyone we're having one June 30, 2029, and see how things go.
If we eliminate leap seconds, we'll need a leap hour in ~500 years. It could be announced 50 years in advance.
> It could be announced 50 years in advance.
Which is about how long it took for folks to switch from the Julian to the Gregorian calendar.
It took much longer than that, although to be fair the Catholic countries had switched in much sooner than 50 years.
In the US DST was changed in 2005 and the change went into effect in 2007.
> 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>
If you think you're going to steal days off my life, you've got another thing coming buster!
> 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.
Just here to reinforce your point.
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 insanity is that both NTP and unix timestamps need to be wound back during a leap second, as well as computer hardware clocks. If we just had monotonic clocks everwhere and adjusted for leap seconds in presentation then we wouldn't have many of the associated problems.
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.
WDYM? Leap seconds are a 61st second, hitting 60 before 00 next minute. https://nrc.canada.ca/en/certifications-evaluations-standard...
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 meant unix and NTP times, which are supposedly just monotonic numbers marching forward (except for leap seconds), not the UTC representation over abstract time.
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.
Yea, can't be arsed to do it right, so let's just not do it.
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.
[0]: https://en.wikipedia.org/wiki/International_Atomic_Time
No, they should not.
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.
Timezones have nothing to do with UTC or unix time. Timezones only come into play when you convert between to other timezones.
Sure; but I happen to be one of the dozens of people who do not live in UTC.
So you have to do the conversion at some point _anyway_.
If your app presents me data making the assumption that _my_ day is always 86400s, it will be _wrong_.
You do not have to do the conversion. It is just for presentation for you and the users. You do not have to read or know anything about TZ.
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.
[0]: https://en.wikipedia.org/wiki/Leap_second#Phase-out_and_futu...
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.
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.
Comment was deleted :(
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.
I thought the state of the art here was to elongate seconds collectively over the course of a long range of time to compensate
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.
Changing a global time system is not a trivial task.
We’re still using a calendar developed over 400 years ago and just making minor tweaks. Without some central global authority, change is unlikely. And even with that, it would be extraordinary disruptive.
The middle for the day, on our time keeping devices, being light outside goes all the way back to the first sundials over 3,000 years ago.
Small and regular maintenance is more realistic than expecting a complete overhaul of timekeeping at some point when are lack of maintenance becomes so problematic that the whole system needs to be thrown away.
Comment was deleted :(
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)
> They teach us Scientific Realism in school.
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.
Statistics is even presented like metaphysical truth. Or at least my experience in engineering school.
And taking fluid dynamics, we used renyolds number, which is a made up ratio that helps for decision making... Its not like when we answered questions, we could answer the grey area we are discussing.
If I had to guess, I think its due to western civilization being built of Platonism (and even Aristotle was infected). Our science and morality is later built by platonic realism. Only in the last 100-ish years are we starting to get over it.
No they do not teach Scientific Realism in schools. We're taught the scientific method and then build upon that.
I can see how someone could misunderstand or forget what they're taught though.
K12 teachers arent educated enough to realize the words they use imply scientific realism.
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.
>we are measuring something real.
I think it matters. No the planets are not doing circles around the sun. Circles don't actually exist, they are doing elipses.
Also 'real' has quite a few meanings. If I ask the question 'Are you closer to a keyboard or the gym?' does that question exist?
This kind of stuff does end up mattering. It becomes much more noticeable in psychology (and biology). If you read Freud, Adler, or Jung, you will say 'Oh extrovert! I've seen that before!' But then you realize its vague and almost always true. Its like a horoscope.
So if we think there is a truth to reality, we look for perfect relations. If we think its impossible for humans to figure out, we look for best fits.
all I want for christmas is a negative leap second
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.
> since 1972, which is only 44 years ago
Thanks for making me a decade younger :)
Can you explain how a 10 minute offset would affect you in any way?
For 99% of the world today, high noon =/= 12:00:00. Nothing breaks because of this. The world continues to run.
I ran into this trying to view the meridian line at the Basilica of Saint Mary of the Angels in Rome.
I was told the sun would show up on the calendar in the floor at noon. As noon approached, I saw nothing. Then I figured it probably needed to be solar noon, so had to look that up and wait around until that time. Today, that will be 12:20pm.
Nothing would have broken had I missed this, and nothing of critical importance is running on a solar clock (I don’t think), but it still led to a discrepancy in what was expected and where I needed to be when, based on drift from solar noon.
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.
> Some years leap seconds need to be added, some years they need to be removed.
Is that true? Per Wikipedia:
> Since [1972], 27 leap seconds have been added to UTC, with the most recent occurring on December 31, 2016. All have so far been positive leap seconds, adding a second to a UTC day; while a negative leap second is theoretically possible, it has not yet occurred.
Either way, it's due in part to Earth's rotation slowing down, so the average drift would still be non-zero.
We've not had to apply negative leap seconds yet since leap seconds were introduced in 1972, but that wasn't the point.
The time period of the Earth fluctuates a lot [0] and actually in 2020 it was less than 24 hours, but not a large enough change to warrant a negative leap second. If you go back to the 1940s, we would had needed negative leap seconds if we had leap seconds at all then, and going back 150 years we would have needed multiple negative leap seconds every year for several consecutive years.
What we can say is that on average, it is close enough to 24 hours and the average over hundreds of years is even closer to 24 hours that it's not worth adding these extra seconds as you'd then need to remove them again later on.
[0] https://c.tadst.com/gfx/900x506/graphlength-of-day.png from https://www.timeanddate.com/time/negative-leap-second.html
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.
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.
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.
Comment was deleted :(
I think the best solution for minimising overall _long-term_ hassle is to switch to using TAI internally and UTC for display.
> The only people who need it are Astronomers.
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.
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?
More like every 2 years.
But yes, point taken.
The counterpoint is that it costs little.
> The counterpoint is that it costs little.
Radical changes to time-related software cost little ? Stop press !
What radical software changes are you doing?
I haven't once done a single software upgrade related to leap seconds.
I mean, in 53 years we have added 27 leap seconds, so in 119 years you'll have to set your alarm a minute earlier if you still want to arrive on time.
There was some talk about a negative leap second† a few years ago:
* 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.
You make it sound like time labels like "23:59:58Z" can perform actions (e.g. to skip or "suppress").
I had to look it up: https://www.timeanddate.com/time/negative-leap-second.html . In proper words, the clock ("the one humanity agrees to use) would skip 23:59:59Z.
I wonder how much chaos a minute that only has 59 seconds would cause. Measurements would be off by that missing second (e.g. a pipeline delivering fuel at 60 liters/minute would surprisingly only have 59 liters in that minute..).
Nobody should be using an API like time(2) or clock_gettime(2)+CLOCK_REALTIME to measure event durations with sub-second precision or accuracy, especially when controlling mechanical equipment. And I'd be absolutely surprised if anybody was when controlling equipment, at least in a regulated industry.
On unix this is what CLOCK_MONOTONIC is for; for one thing, the real-time clock can be reset at any time. Technically even CLOCK_MONOTONIC could jump forward. Real-time embedded systems either provide other timing APIs, or make additional guarantees about CLOCK_MONOTONIC's behavior.
I feel like most of us don't know what we're actually doing when we do t2-t1 to get a duration. Feels like it'd be in a lot of places and a negative number is going to cause havoc. Even worse if it's an unsigned int and you roll over to some massive duration.
> I wonder how much chaos a minute that only has 59 seconds would cause.
The FreeBSD folks test(ed?) their code for these things and it works:
* https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove...
Of course third-party userland code understanding what happens is another thing.
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.
The length of day increases by around 1.7 milliseconds per century long term (due to the moon’s gravity continuously slowing down Earth’s rotation), which without leaps seconds translates to around one total minute per century. Note that this is cumulative: next century you will need two leap minutes, and so on. Of course, there are significant shorter-term variations in Earth’s rotation due to other factors, so it isn’t quite that smooth in practice.
There was a resolution in 2022 to make a decision in or before 2035, to increase the allowable deviation from one second to a longer interval, like one minute. But that would become more frequent in the long run as well, and likely would still cause disruptions whenever it happens. Though on the other hand there would likely be a longer advance notice for it as well.
I think in 100 years more or take if the exponential curve doesn't level off we're gonna each near super intelligence and some form of fusion at minimum. At worst we just eradicate ourselves.
I would rather suggest a contrary: do smaller increments more frequently. This way it is easier to test and if something goes wrong you know it quicker. Kind of like running your CI pipeline on every commit vs nightly. Going to millisecond adjustments seems, however, very impractical.
That's much worse than the Y2K problem.
The idea is that we've advanced so far that it is simply not a problem anymore.
I assumed that leap seconds could be determined algorithmically, it appears I assumed badly. This is a bit of a can of worms...
They basically are, the algorithm is something like:
At the beginning of january and july, observe the difference between UT1 and UTC. If the difference is >= 0.6s, a leap second will be inserted at the end of june/december. Publish the results here: https://hpiers.obspm.fr/eoppc/bul/bulc
This is true. They look at how much the earth spun, and whether it was more or less than 86400 seconds/day average. This can't be done without external data. It's not a pure mathematical algorithm.
Waiting until Trump discovers that the earth rotation service exists and forces them to insert a negative leap second just because he can.
Oh thank God I thought I was going to make it through a thread on leap seconds without a political discussion
Is it that surprising? Elsewhere in the thread, people are discussing the best smear tactics!
Then, when the stock market crashes due to software failures and timing inconsistencies, he'll want to undo it and thereby cause even more chaos ;)
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.
Every 10 years is just the right frequency that most software breaks, but it causes frequent pain for everyone. Switching to leap hours that have to be dealt with every few thousand years would be much preferable.
[dead]
[dead]
[dead]
Next up: DOGE cancels leap seconds. /s
[flagged]
You need therapy ASAP.
Crafted by Rajat
Source Code