Live data from Hacker News

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

lists.iana.org

151–159 of 159 posts

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

#151
post #125
post #95

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…

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 th…

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

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

#152
post #129

Earlier quoted context omitted.

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

A Martian sol (day cycle/rotation) is > 24 hours (by about 40 minutes). Locked in seconds seems to be the easiest for general use mathematically. 24 hours in a day is a bit of a leftover from sundials and 12 being one of the easiest large fractions of a circle and the Earth day was never really a universal anyway, just an accident of where and roughly when we lived. On the other hand, the modern metric second is now defined at exactly 9,192,631,770 periods of Cesium-133 for atomic clocks and other reasons, so a locked second is useful for a lot of reasons.

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

#153

Earlier quoted context omitted.

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

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.

I believe Vancouver is west enough in its time zone that Daylight time is going to be closer to Solar Noon in Vancouver (plus about 15 minutes? I haven't done the exact math) than Standard time was (minus about 45 minutes?). Vancouver is the economic heart of British Columbia and near enough to the centroid of BC's population that BC may have made the best choice they could for solar accuracy for the majority of the population.

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

#154
post #150

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.

We're still using a calendar that was essentially created by Julius Caesar (with a slight adjustment by Pope Gregory). I think you're underestimating the power of continuity.

Keep in mind that the calendar we use today is off by 13 days from the one in use 2000 years ago. We’re talking about an hour difference in 6,000 years.

6,000 years ago is 1,000 years before Stonehenge.

And this isn’t about whether we use the same calendar, we’re talking about whether we have time keeping continuity down to the second. This requires infrastructure continuity and essentially no adjustments whatsoever over that time.

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

#155

Earlier quoted context omitted.

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

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…

> By the time of Julius Caesar, the solstices were on the 25th

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.

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

#156
post #137

Earlier quoted context omitted.

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.

Do you consider implementing filters like “filter these items to those that have happened in a given day/week/month” a “presentation issue” too? Because you need TZ awareness to implement that in a way that most humans expect.

[deleted]

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

#157
post #4

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 $wo…

Very similar story at $mywork in 2016.

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

#158
post #149
post #147

Earlier quoted context omitted.

I've implemented exactly the filter you're describing. Yes, it's essentially a presentation issue. There are 2 common ways to represent time: something akin to Unix time, which is just a scalar number representing the offset from some global reference instant (the epoch), or as "clock-calendar parameters" i.e. year-month-day-hour-minute-second. It's much more natural for software to operate entirely on the former rep…

I think if your definition of "presentation" includes "parsing"; then we have very diverging definitions; but at least I understand we're mostly on the same page.

I programmed systems with both for many years -- the thing that needs to be defined early is whether your time an Instant or a Date/TimeOfDay/Quarter (collectively Naked)

Instant would be like log entry timestamp. Can be represented as unix time or SQL Timestamp.

Naked would be a "contract effective date" or "employment first day" or "invoice date" or "store opening time". Do not try to use an Instant to store it (e.g. timestamp at midnight to represent a day) or you're about to have a bad time later.

Instants are more prevalent in systems engineering, Nakeds -- in applications.

Only when you need to present the Instants to the user you need to convert them to strings and timezones come into play. Nakeds rarely need to be translated to Instants (e.g. when deciding if an invoice is overdue and send a email notification).

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

#159
post #105

Earlier quoted context omitted.

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.

Thanks for explaining! It's indeed crazy that "this is still a thing".

(I regret I did not put in the research prior to answering to your comment: https://www.meinbergglobal.com/english/info/leap-second.htm#... )

Post reply on HN