Hacker News Reader

Comment by imglorp | Hacker News Reader

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.

View on HN

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

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.

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.

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

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.

The rest of the world should abandon UTC completely. It's not suitable for time keeping because butt scratching hairless monkeys mess with it.

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.

In the US DST was changed in 2005 and the change went into effect in 2007.

It took much longer than that, although to be fair the Catholic countries had switched in much sooner than 50 years.

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.

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

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.

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

> 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

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

"Basic" made me lol :)

"And so the Y10K problem was born"

I’d better go brush up on my COBOL

Programmer-Archaeologist will be quite a coveted position 300 gigaseconds from now.

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.

> 7200 years ago the Neolithic revolution was still in full swing

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

https://en.wikipedia.org/wiki/Old_Kingdom_of_Egypt

https://en.wikipedia.org/wiki/Stonehenge

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

25-hour days.

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

You could look at it either way. I couldn't say which system the dinosaurs actually used.

I have it on good authority they just used unixtime for everyone but put all the leapseconds in the tz table.

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.

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

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

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.

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

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

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.

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

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

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.

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

Yea, can't be arsed to do it right, so let's just not do it.

Very similar story at $mywork in 2016.

Reply on news.ycombinator.com