Live data from Hacker News

Leap second hiatus

fanf.dreamwidth.org

61–70 of 117 posts

Re: Leap second hiatus

#61

Many computer programs use UTC time (which means you have to deal with leap seconds) when they really should be using TAI (which is based purely on the physical progression of time on the earth's geoid, with no arbitrary input that has to be updated periodically). https://cr.yp.to/proto/utctai.html Generally, you should only be dealing with UTC for things that have to display/accept a time to/from human users; there'…

TAI is for keeping track of chronology in this gravity well of ours. UTC is for exposing this as a culturally useful value. UTC uses TAI.

Re: Leap second hiatus

#62
post #2

> NTP or kernel timekeeping code expects that it will be an appalling shitshow. I’m curious what systems would catastrophically fall apart if time went back one second?

A negative leap second (the appalling shitshow from the article) would make us skip a second, though. Going back one second is what generally happens now when a Linux box does the "inserting leap second" thing. It goes from 23:59:59.999999 to 23:59:59.000000, then runs that whole second again. You get to 23:59:59.999999 again, and then you finally roll over to 00:00:00.000000. From the perspective of the typical time…

>'From the perspective of the typical time_t rendering of Unix time, there is no way to uniquely represent that 61st second. It just "disappears".'

This is a great and really intuitive summary of the problem. Is there a certain class of problem related to disappearing second? Like are these more likely to be filesystem issues or things that rely on timestamps? Or are there second order problems as well?

>"I can tell you that what died at that particular site was all of the locking code that used wall time clocks instead of monotonic clocks. They all CHECKed and died when their preconditions were no longer valid. I can tell you that what died at that particular site was all of the locking code that used wall time clocks instead of monotonic clocks. They all CHECKed and died when their preconditions were no longer valid."

Sorry if this is a silly question but was that check simply that "time t1 is greater than time t0"? Also was the duration of that outage(17 seconds) or would this have been equally catastrophic at a single second?

Re: Leap second hiatus

#63
post #35

Re: the 'negative second' fears - in usual operation, NTP adjusts your local machine downward all the ... time. There's really nothing to be afraid of; a few services would implement some skew, the rest of us would get NTP updates and life continues.

What about my DIY double entry book system I wrote using various JavaScript libraries?

I have no clue.

Re: Leap second hiatus

#64

Many computer programs use UTC time (which means you have to deal with leap seconds) when they really should be using TAI (which is based purely on the physical progression of time on the earth's geoid, with no arbitrary input that has to be updated periodically). https://cr.yp.to/proto/utctai.html Generally, you should only be dealing with UTC for things that have to display/accept a time to/from human users; there'…

This is what I'd _like_ to do, but unfortunately it's not well supported. As far as I know, all OSes store the time including leap seconds, so there's no way to go back to TAI. And even if it were, that time zone is not available in user programs.

edit: Oh, I see that it's available in Linux https://www.man7.org/linux/man-pages/man3/clock_gettime.3.ht... . Can't find similar calls for Windows or OSX

Re: Leap second hiatus

#65

Many computer programs use UTC time (which means you have to deal with leap seconds) when they really should be using TAI (which is based purely on the physical progression of time on the earth's geoid, with no arbitrary input that has to be updated periodically). https://cr.yp.to/proto/utctai.html Generally, you should only be dealing with UTC for things that have to display/accept a time to/from human users; there'…

This is what I'd _like_ to do, but unfortunately it's not well supported. As far as I know, all OSes store the time including leap seconds, so there's no way to go back to TAI. And even if it were, that time zone is not available in user programs. edit: Oh, I see that it's available in Linux https://www.man7.org/linux/man-pages/man3/clock_gettime.3.ht... . Can't find similar calls for Windows or OSX

> The acronym TAI refers to International Atomic Time.

Good one. Wikipedia[0] is more helpful and states it comes from "temps atomique international" which is french.

[0]: https://en.wikipedia.org/wiki/International_Atomic_Time

Re: Leap second hiatus

#66
post #49

Earlier quoted context omitted.

Besides the sibling comment that some things rely on the days being synced to rotation, doing it once a century would pretty much guarantee that only the most obsessively robust systems would take it into consideration when being built. We'd be giving ourselves a Y2k-equivalent to deal with every century. Maybe that's not the biggest deal in the world, but I still remember the last viscerally and we're already a fift…

> doing it once a century would pretty much guarantee that only the most obsessively robust systems would take it into consideration when being built. tzdata updates happen all the time (in a relative sense). So code would need to handle those, and I don't see why potential leap hours couldn't be handled like that. Just means that Europe/London eventually will be +01:00 (or is it -01:00, anyways) instead of +00:00 it…

[deleted]

Re: Leap second hiatus

#67

Earlier quoted context omitted.

Besides the sibling comment that some things rely on the days being synced to rotation, doing it once a century would pretty much guarantee that only the most obsessively robust systems would take it into consideration when being built. We'd be giving ourselves a Y2k-equivalent to deal with every century. Maybe that's not the biggest deal in the world, but I still remember the last viscerally and we're already a fift…

"If it hurts, do it more often" — Martin Fowler

Practice makes perfect. Release early, release often.

Re: Leap second hiatus

#68
post #49

Earlier quoted context omitted.

Besides the sibling comment that some things rely on the days being synced to rotation, doing it once a century would pretty much guarantee that only the most obsessively robust systems would take it into consideration when being built. We'd be giving ourselves a Y2k-equivalent to deal with every century. Maybe that's not the biggest deal in the world, but I still remember the last viscerally and we're already a fift…

> doing it once a century would pretty much guarantee that only the most obsessively robust systems would take it into consideration when being built. tzdata updates happen all the time (in a relative sense). So code would need to handle those, and I don't see why potential leap hours couldn't be handled like that. Just means that Europe/London eventually will be +01:00 (or is it -01:00, anyways) instead of +00:00 it…

I can't speak to how different parts of society will interact in hundreds of years, but if today there were going to be a leap hour and programmers requested that we start considering London to be in +01:00, the chances of politicians or public agreeing with that request is nil.

Re: Leap second hiatus

#69

Earlier quoted context omitted.

Besides the sibling comment that some things rely on the days being synced to rotation, doing it once a century would pretty much guarantee that only the most obsessively robust systems would take it into consideration when being built. We'd be giving ourselves a Y2k-equivalent to deal with every century. Maybe that's not the biggest deal in the world, but I still remember the last viscerally and we're already a fift…

> I see no reason why DST code (which is generally implemented as an extra timezone) could straightforwardly be adapted to handle a single permanent shift of time. The point is that we don't have to add the additional code to handle leap hours, as it can be implemented as a large swath of time zone changes. We can imagine that there would be two versions of UTC, one before the leap hour (hereafter UTC) and one after…

The problem is not that changing the code is complicated. Changing code to accommodate four-digit years wasn't complicated. The problem is that you have to change every single piece of software which uses time. What you're proposing is exactly what I think needs to be avoided.

Re: Leap second hiatus

#70
post #16

What causes changes in the rate of rotation of the earth?

The angular momentum of the "earth system" is constant [1]. The variation in angular velocity of the solid earth can be ascribed to change in the angular momentum carried by oceans and atmosphere. These changes can be due to change in velocity (winds, currents) or moment of inertia (moisture in atmosphere). [1] If we ignore friction due to tidal forces from moon and sun (which is valid on these time-scales), the "ear…

Right.

But tidal forces are not completely irrelevant to leap seconds.

The length of the atomic SI second was calibrated to match the previous sidereal second, which was based on the length of a year. In practical terms, the sidereal second was based on Newcomb’s Tables of the Sun, which was a model of the solar system developed at the end of the 1800s based on historical astronomical observations https://en.wikipedia.org/wiki/Newcomb%27s_Tables_of_the_Sun

So the length of the second is based on the length of the year 1900, and derived from older astronomical measurements of the rate of movement of bodies in the solar system.

Leap seconds exist because by the 1960s the length of day no longer matched Newcomb’s calculations for 1900: it was longer by 1 or 2 milliseconds.

Post reply on HN