Live data from Hacker News

No leap second will be introduced at the end of December 2026

datacenter.iers.org

201–210 of 259 posts

Re: No leap second will be introduced at the end of December 2026

#201
post #98
post #85

Earlier quoted context omitted.

"In other words, we want UTC noon to be within a second of mean solar noon on the prime meridian." Why? If I travel 1 mile east or west of the prime meridian, my solar noon now comes 2-3 seconds earlier/later. It's nearly impossible to have your local time match your local solar noon. For most of the population, solar noon is, on average, 30 minutes off of 12:00 noon. Plus, solar noon varies from day to day by 10-20…

> Why? Um, because it's the prime meridian and that's how UTC is defined? > It's nearly impossible to have your local time match your local solar noon. Which is why I specified on the prime meridian, which is the particular local meridian that UTC is defined as corresponding to. > solar noon varies from day to day by 10-20 seconds. Which is why I was careful to specify mean solar noon. I'm not quite sure what your is…

> Um, because it's the prime meridian and that's how UTC is defined?

That's an explanation of how it is, not why we should care to preserve it.

The definitions of hours minutes and seconds have changed before, and in recent history.

> Which is why I was careful to specify mean solar noon.

And "mean solar noon" is meaningless to people's lives. Even in the areas where time zones do follow meridians and not country borders that are many minutes off.

Re: No leap second will be introduced at the end of December 2026

#202
post #104

Earlier quoted context omitted.

Same with leap days though? The point is that it's weird that we handle a day every 4 years off in a different way to a couple of second being off.

The leap day system handles the mean, the leap seconds handle the variance around the mean. The need for leap seconds is not predictable—they zero out accumulated error.

No, they handle totally different things. Leap seconds handle the earth spinning at a varying speed. They would be a problem even if the sun didn't exist. Leap years handle the fact that earth spins don't evenly divide orbits around the sun. They would be a problem even if clocks didn't exist.

We can imagine a system where leap days are split into mean and variance: This would look like a council coming together every thousand years to decide if that year will have a leap day or not, but otherwise we follow the pattern.

We can also imagine a system where leap seconds are split into mean and variance: Many years from now when the Earth is notably slower, there's a guaranteed leap second every odd month, and sometimes there's an extra leap second in June.

Re: No leap second will be introduced at the end of December 2026

#203
post #118

Hear me out. We can just mount jet engines along the equator and rotate them 180 to gain or lose time. And then connect them to my snooze button.

You could actually move very large quantities of water around and probably have a measurable impact. Like draining the California central valley aquifer.

The Three Gorges Dam has already given us 22 more microseconds in the year. Basically, the Chinese have converted the angular momentum of every molecule on Earth, including you... into electricity.

Re: No leap second will be introduced at the end of December 2026

#204
post #134

Earlier quoted context omitted.

Heh, I like the analogy but my question was really why it was considered such a hassle. I mean we deal with daylight saving time all the time and I know it's not the same because the leap second affects UTC, not just local time zone, it's just that you are either dealing with monotonically increasing time like epoch, or you are dealing with "human" time and I found no distinction in the latter. Is it "just" that leap…

It's a hassle for anybody doing or recording "physics" as they cannot log against UTC (which may or may not have an added second or removed second in some interval if it happens to overlap the adjustment zone). Those things that really do rely on actual "elapsed time" rather than the difference between two recorded "book times". Does this happen? Yes, a few times in my career in geophysical exploration - it's why mul…

The most annoying part is that a lot of GPS gear automatically "corrects" to UTC without giving clear indication of it. Things would'be been fine if the standard was to explicitly sent out TAI timestamps, with a leap second offset for the people who insist on UTC.

Re: No leap second will be introduced at the end of December 2026

#205

Earlier quoted context omitted.

2035 is the agreed drop dead date. Everybody agreed that "Leap seconds" are a sufficiently bad idea that they should be replaced by 2035. Nobody has agreed how to fix it, and "Just turn them off" isn't technically legal. However, "What if there were Leap hours instead?" is technically legal and of course those hours would happen in the very distant future (likely after our civilisation is gone) so it's functionally i…

On the subject of amusing British political legislation, should he defeat Nigel Farage in the resulting by-election Count Binface will not be able to wear his costume in Parliament; not only is business attire required in the House of Commons, it's specifically forbidden to wear a suit of armour there due to a law from the 14th century. For those unaware, the major parties have declined to participate in the by-elect…

Comments like this make me really worry for the future of Hacker News. Here we are, on a seemingly informative thread, and you’ve jumped in with baseless political propaganda no doubt designed to influence the upcoming election.

His honour Count Binface is from Sigma IX not Sigma 6! To lump him in with those scurrilous, pro-littering hoodlums is the kind of anti-Recyclon smear I would associate with Sigma X’s online forums, not this place!

Re: No leap second will be introduced at the end of December 2026

#206
post #204

Earlier quoted context omitted.

It's a hassle for anybody doing or recording "physics" as they cannot log against UTC (which may or may not have an added second or removed second in some interval if it happens to overlap the adjustment zone). Those things that really do rely on actual "elapsed time" rather than the difference between two recorded "book times". Does this happen? Yes, a few times in my career in geophysical exploration - it's why mul…

The most annoying part is that a lot of GPS gear automatically "corrects" to UTC without giving clear indication of it. Things would'be been fine if the standard was to explicitly sent out TAI timestamps, with a leap second offset for the people who insist on UTC.

Well, yeah, that to - although TBH it's never been an issue in my line of work which started with (LORAN actually, and then moved to..) off book reverse engineering of the OG NavStar format. To this day it's still "raw" GPS packets that are logged - and later post processed for greater accuracy (and often blended with a local area fixed position base stations "corrections" for GPS fix wobble).

There's a lot of fiddly pedantic stuff that goes with scientific data recording, timekeeping is but one domain of possible issues.

Re: No leap second will be introduced at the end of December 2026

#207

Earlier quoted context omitted.

Hilariously, no. That would be the Monster Raving Loony party who will apparently also be standing in this by-election. Count Binface has ruled out a pact with them.

I was very disappointed to hear that the Monster Raving Loony party is deciding to stand and split the vote. I thought this was an opportunity for them to be tactical, but no. (this is a joke)

Binface's speculation to the media is that the Monster Raving Loony party may split the vote with Farage instead as that is closer to where his loyalties lie.

Re: No leap second will be introduced at the end of December 2026

#208
post #23

Earlier quoted context omitted.

really, my I just don't have the time to keep up with this.

A leap hour wouldn't affect you. In practice it will never affect anyone because it's a legal fiction, but even if you pretend to believe we would actually introduce this "leap hour" it would be in the distant future long after we're all dead and if there are still humans who have any idea the year 2026 happened they're not sure which of Donald Trump, Taylor Swift, Tony Stark and John McClane were real people. Edited…

Timekeeping is timeless. We count the number of orbits around the Sun from a specific guy's birthday 2000 years ago, our 12 months are named after rulers of an empire that hasn't existed for almost as long, and weekdays are named after the pagan gods that guy replaced. I don't know why there are 7 days in a week, but supposedly there are 86400 seconds in a day because some Bronze Age people liked the numbers 60 and 12.

Even if one day humans have to account for relativity in their commute, their woes will pale in comparison with those of the poor soul who has to add support for it in a C library that only understands (now, 128-bit) Unix timestamps.

Re: No leap second will be introduced at the end of December 2026

#209

ELI5: How does this impact UNIX timestamps? Particularly for things that are in maintenance mode or otherwise minimally maintained. Nothing I do requires this level of precision, but certainly there are things that do.

Yes, time() and clock_gettime(CLOCK_REALTIME) results are affected by leap seconds.

New leap second will get to your system through NTP. Sadly NTP only distributes indicator flag that leap second is going to be introduced, but not the offset itself. But the distributed time itself is already affected by leap second, so NTP client doesn't really need to know.

(In contrast the other time sync mechanisms - GPS and PTP - use time scale unaffected by leap seconds and distribute it as an additional information with UTC offset. And it's left on client to modify received time on its end. Kernel has a parameters in clock_adjtime() for leap seconds.)

So if you have a passive system that has NTP client then it's time will change for new leap second on runtime. Linux treats UTC time as the dominant one, so that's the one saved to RTC device and will survive reboot.

There is CLOCK_TAI that sounds like it should return TAI time, but it is such a second class citizen to the point that nothing on regular Linux desktop and server distros even set the offset and it returns the same time as CLOCK_REALTIME.

There is a file in /etc with list of leap seconds that is part of some package, so you need to update the system to update this file. I don't believe traditional NTP software updates this package dynamically. But not many software uses it. If some init service script parsed and set the kernel UTC offset then your system's CLOCK_TAI would be one second late from rest of the world until update. But it doesn't affect UTC time on Linux in any way I know.

Re: No leap second will be introduced at the end of December 2026

#210

Earlier quoted context omitted.

A leap hour wouldn't affect you. In practice it will never affect anyone because it's a legal fiction, but even if you pretend to believe we would actually introduce this "leap hour" it would be in the distant future long after we're all dead and if there are still humans who have any idea the year 2026 happened they're not sure which of Donald Trump, Taylor Swift, Tony Stark and John McClane were real people. Edited…

Timekeeping is timeless. We count the number of orbits around the Sun from a specific guy's birthday 2000 years ago, our 12 months are named after rulers of an empire that hasn't existed for almost as long, and weekdays are named after the pagan gods that guy replaced. I don't know why there are 7 days in a week, but supposedly there are 86400 seconds in a day because some Bronze Age people liked the numbers 60 and 1…

Yeah, nah - that "we" doesn't cover all the other calendars also in use.

  The Julian period is a chronological interval of 7980 years, derived from three multi-year cycles: the indiction, solar, and lunar cycles. The last year that was simultaneously the beginning of all three cycles was 4713 BC (−4712), so that is year 1 of the current Julian period, making AD 2026 year 6739 of that Period.
~ https://en.wikipedia.org/wiki/Julian_day

> Even if one day humans have to account for relativity in their commute

You don't think there aren't already application domains that have to account for relativity differences between reference frames?

Post reply on HN