Hacker News

> 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.

[1] https://en.wikipedia.org/wiki/Leap_second

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.

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.

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.

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.

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.

>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.

We had a leap hour yesterday...

> 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.

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.

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.

[0]: https://en.wikipedia.org/wiki/Leap_second#Phase-out_and_futu...

>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.

Most of the world is perfectly fine with 12:00 not being synchronized with high noon [0]. And some jurisdictions still semiannually f*k with it further using DST. Generously assuming the current time keeping system will survive for ~6k years (looking at the leap seconds accumulation rate for the last 50 years) we can just shift timezones by one hour.

[0]: https://64.media.tumblr.com/4a9a4613f057d3b5f17ec548e6ac06d1...

> 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.

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.

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.

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?

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.

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.

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.

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.

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 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.

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.

The idea is that we've advanced so far that it is simply not a problem anymore.

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.