Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leap second hiatus

fanf.dreamwidth.org

Post reply on HN
Print view View original

91–100 of 117 posts

Re: Leap second hiatus

#91

Post by btilly »

bloak wrote: post #58
labster wrote: post #15

Can we take a longer hiatus on leap seconds, maybe 79 years or so, and only update once a century? Local apparent noon being off by 30 seconds or so has approximately zero impact on my daily life, but stupid things in datetime libraries do occasionally have impact. If we can’t throw off the oppression of UTC and greet TAI as liberators, at least adjust the clock at regular, very infrequent dates.

People who can't cope with leap seconds should stop pestering the people who define UTC and just switch to TAI. They can do that now. No one is stopping them. Leap seconds are a pain and I myself would happily choose TAI over UTC for the system clock on a typical embedded system. However, for civil time keeping and for some technical purposes, UTC as currently defined is exactly what we need. Don't fuck with it.

No, they can't.

Programmers have to deal with the outside world. The outside world has timezones defined as offsets from UTC. So when UTC changes, the whole world changes their clocks, and programmers have to cope. If your program doesn't agree with that world about what time it is, your program will get blamed.

If it was a choice that I could individually make, I would tell astronomers to go pound sand. But it isn't. By historical happenstance, they have been put in charge of time, and it is truly a question of the tail wagging the dog when they care about a 1 second deviation between UTC and the position of the sun at a particular longitude.

Re: Leap second hiatus

#93

Post by ay »

We should have two “keep on your toes” leap seconds per year, one +1 and one -1 (can it be done ?) in lieu of daylight savings time or together with it for those that still keep it.

Re: Leap second hiatus

#94

Post by btilly »

forgotmypw17 wrote: post #90

> At the moment the Earth is rotating faster than in recent decades: these shorter days, with a lower length-of-day, means the milliseconds accumulate more slowly, and we get fewer leap seconds. Does anyone know why Earth's rotation has sped up?

The biggest factor is thought to be core-mantle coupling.

The Earth is built in layers. The solid bit we see is called the crust. Then there is a liquid layer where heat melts rock, that's called the mantle. And then at the center of the Earth the pressure again turns things solid, that's called the core.

All of the things affecting the Earth's rotation in the long term pull on the crust. The two biggest are tides (slows us by 2.3 ms/century) and glacial rebound (estimated to speed us up by 0.7 ms/century). The result is that the crust and the core wind up turning at different rates, and interact with each other through the mantle. Which transfers angular momentum back and forth between the crust and core.

The article that first showed this is https://www.nature.com/articles/333353a0 if you want to look further.

Re: Leap second hiatus

#96

Post by rachelbythebay »

bogomipz wrote: post #62
rachelbythebay wrote: post #8

Earlier quoted context omitted.

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…

Well, okay, so, the problem is like this: let's say you wanted to schedule something to happen during that exact extra second in the end of June 2015 when we were all standing around watching UTC do its little extra dance. You pick 1435708800. Trouble is, that Unix time applies to both 23:59:59Z and 23:59:60Z on that particular day.

You can't target it beforehand or after. It's just... gone.

It's not a problem from the point of view of programs, since they just got whatever time_t value they got, and they don't know the bigger perspective. It's more of a mapping from outside->in problem.

Put it another way: try writing a program that'll call clock_gettime() and will say a message at a later time you select. You can't put in 23:59:60Z because there's no way to represent it, and indeed, you won't even be able to tell when the time comes unless you special-case it and notice _that particular second_ repeating itself... or reach into the kernel to look at the leap bit, or worse. It's a real time in meatspace, but you can't target it with the tools at hand. That's the problem.

Regarding the 17 second thing, that's because someone decided to switch off the thing which (correctly) applies the adjustment factor to GPS time to make it NTP time. There was a 17 second difference at the time (GPS to NTP), and with it off, we were shipping GPS time to hosts as if it was NTP time.

In theory, any regression of the clock long enough to not let the actual passing of time push it past the sanity check time point in the lock stuff would have caused this. The thing is, a small-scale time step (from ntpd, say) normally happens at boot up, not later, and it's on a system by system basis.

The 17 second excursion happened on hundreds of thousands of machines all at once, and, yeah, it was noticed.

Re: Leap second hiatus

#97

Post by guenthert »

welterde wrote: post #59
Dylan16807 wrote: post #29

Earlier quoted context omitted.

Precision isn't a binary, it's a continuum. The question at hand is whether there are significant use cases where 1 second of slack in matching the Earth's rotation is acceptable, but 30 seconds is too much. GPS isn't an example of that because 1 second is already a quarter mile off.

Pretty much all telescopes (under computer/time control) on this planet rely on UTC being quite close to UT1, since every second difference leads to a 15 arcsecond error in the pointing of the telescope (error between where you want to point the telescope on the sky and where you are actually pointing). While <5s is usually not a problem (except for some instruments with very very small FoV), at 30s it really becomes…

I would think this is an argument for telescopes using UT1, not whether UTC should be adjusted for leap seconds. This is such a fringe application and all involved are aware of the issue, that I don't think it's relevant here at all.

Re: Leap second hiatus

#99

Post by NovemberWhiskey »

mdpm wrote: 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.

I think the concern is more about whether the negative leap second handling in all of the different, interacting NTP server implementations (which have never been exercised in the wild) will be good, bad or ugly.

If you read around the topic, there was plenty of non-conformance for the relatively recent leap seconds.

As you say, clock skewing happens continuously in NTP so that part looks proven.

Re: Leap second hiatus

#100

Post by revicon »

forgotmypw17 wrote: post #89
labster wrote: post #15

Can we take a longer hiatus on leap seconds, maybe 79 years or so, and only update once a century? Local apparent noon being off by 30 seconds or so has approximately zero impact on my daily life, but stupid things in datetime libraries do occasionally have impact. If we can’t throw off the oppression of UTC and greet TAI as liberators, at least adjust the clock at regular, very infrequent dates.

How does TAI relate to Epoch time? More and more I use Epoch time for most things just because of how convenient it is. I rarely need sub-second granularity, and it's just one number, so it's sortable, math-able, etc. Then whoever is doing the display can convert it any way they want to.

Remember that your code needs to account for the possibility of a negative leap second, meaning if you're using epoch time for timestamps you could have an instance that an event that happened after a previous one could be stamped as having happened before it instead.

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

Edit: Actually I was slightly wrong, in the event of a leap second, we would repeat the same second twice.

Post reply on HN