Live data from Hacker News

Ask HN: Are systems ready for the first negative leap second?

news.ycombinator.com

91–100 of 100 posts

Re: Ask HN: Are systems ready for the first negative leap second?

#91
post #25

Earlier quoted context omitted.

What's worse about negative leap seconds? The "experienced" time by systems will just look like they froze for a second. Added leap seconds are worse, surely, as time goes backwards.

Suppose being charged by time used to run your tasks. Then your task takes -1 second, you will be charged zero, 1 second, or 18 quintillon seconds?

That's exactly what I see happening when a leap second is ADDED.

A leap second is added. The system goes "oh shit, I'm a second ahead", and subtracts a second. And that's how you get a negative duration and exactly this problem.

Whereas if a leap second is subtracted, you get charged for an extra second.

Re: Ask HN: Are systems ready for the first negative leap second?

#92
post #52

Earlier quoted context omitted.

Indeed. I like to say, we would like three things to be true: 1) Every day has 86400 seconds. 2) Every day is from noon (sun exactly above) to noon (sun exactly above). 3) We use SI seconds. You can't have all three. Pick any two: 1, 2, not 3: What you describe. Day has 86400 seconds, we keep in sync with the sun, but we tweak the seconds a bit. There are different versions, like epoch time, or UT1. 1, not 2, 3: Ever…

Unless you're an astronomer, you probably don't care about condition 2. Many countries still shift wall time around by an hour twice a year for DST - if people are okay with that, solar time being offset by a few seconds is insignificant. Even for astronomers, I suspect that preserving conditions 1 and 3 is probably more valuable than 2. It's easier to correct for the uneven rotation of our planet than for an uneven…

DST cancels itself out, leap seconds don't.

And sure, being off by a few minutes isn't a big deal, but it gets really annoying for day-to-day life when it is off by a few hours. Suddenly your "midnight" is happening at solar noon!

Re: Ask HN: Are systems ready for the first negative leap second?

#93
post #40

I don't think we're going to do any negative leap seconds. https://www.yahoo.com/news/science/articles/international-ti... I think we're voting to change to a leap hour in early 2027. Or I'd assume we're going to go that route instead of continuing to entertain the tech nightmares.

We've on track to do something different before the end of 2035: https://en.wikipedia.org/wiki/Leap_second#Phase-out_and_futu... Shifting to a leap-minute feels close-enough to me: We might get one every 50 or 100 years. A lot of us reading this today will never live to see a leap-minute, but it's close enough that we'll still have it collectively in-mind when it it needs to happen. (And if we screw it up at that tim…

Every 50 or 100 years is possibly the worst way of dealing with it. You're essentially making it a repeating Y2K / Y2038 problem.

Doing it that rarely means most people will never see it happen in their professional life, so most processes will be designed without keeping it in mind. When it does inevitably happen, everything breaks at once.

With leap seconds it happens often enough that you actively have to keep it in mind during design. Leap hours are rare enough that they'll be a society-wide event, and can probably be handled without too much issue using existing timezone logic.

Re: Ask HN: Are systems ready for the first negative leap second?

#94
post #49

Earlier quoted context omitted.

> A leap-hour, meanwhile: That kicks the can so far down the road that we'll probably lose track of it completely. 600 years is a very long time; society will be a very thing by then. Leap-hours seem to me to be moral equivalent to the "fuck it, let's just give up" option. Something to consider: The use of timezones in mostly 1-hour increments over inconsistently placed areas means that the vast majority of people ar…

An extreme example is Xinjiang, where solar time can be more than three hours off from civil time (due to the PRC policy of having only one time zone for all of China).

Xinjiang is well-known for effectively operating in two timezones at once, with part of the population mostly operating on +6 and part on +8.

Re: Ask HN: Are systems ready for the first negative leap second?

#96

Earlier quoted context omitted.

That shouldn't be the case? When a negative leap second is applied it just means that 23:59:59 is skipped. The seconds go 56 57 58 0 1 2 3. vs a positive leap second where time goes 56 57 58 59 60 0 1 2 3. So if you are billed by time and it's tracked via a timer then your time is still accurate but if it's tracked by reading your start and end time then your billing will just read an extra second. Positive leap seco…

> just read an extra second [...] accidentally trigger watchdogs Well, this seems to touch heavily on the concern: if your job normally takes 0.1s and costs $100, it could accidentally be considered to have taken 1.1s and therefore cost $1100. This is quite contrived, but if you consider that some people put very infrequent cron jobs at the top of the hour (which isn't typically the best idea, but I digress) and it m…

Yeah definitely but tbh a one-off expense at that scale while unfortunate isn't really lethal.

And tbh if you are performing ops at a scale where that level of expense is present it's nobody's fault but your own if your orchestration is cronjobs on the 58th second of the 59th minute of the last hour of the year.

And at any time scale past the order of seconds, this is a small enough time jump that it's a rounding error in ops expenses.

Re: Ask HN: Are systems ready for the first negative leap second?

#97
post #66
post #12

Earlier quoted context omitted.

negative leap seconds aren't too bad. jumping forward a second won't lead to a time loop like jumping back did on several systems (some twice!)

Unless you have something scheduled for that second.

In a "realtime system", sure. But for almost all workloads programs have to deal with overshooting. Like, maybe CPU overloaded or swap intensity caused that second to "disappear". On almost all workloads you can't just assume that you'll execute on every single second.

And if you do need to be scheduled on every second, well you always needed to use a monotonic time.

Negative leap second should only cause measurements to be off by a second, at worst. Added leap seconds means time goes backwards, which is worse.

Of course NTP can cause either.

Re: Ask HN: Are systems ready for the first negative leap second?

#98
post #56
post #54

Earlier quoted context omitted.

Now imagine blood pump during surgery.

I’m horrified to imagine a blood pump or any life support system being network connected, or to rely on the precise time of day in order to function correctly. Accurate time keeping for anything in this realm can and should be done without a network.

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

Re: Ask HN: Are systems ready for the first negative leap second?

#100
post #98
post #56

Earlier quoted context omitted.

I’m horrified to imagine a blood pump or any life support system being network connected, or to rely on the precise time of day in order to function correctly. Accurate time keeping for anything in this realm can and should be done without a network.

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

The equation is different if the life saving surgery couldn’t be performed otherwise. Still pretty crazy and I don’t know how comfortable I’d be with it if I were the patient.
Post reply on HN