Live data from Hacker News

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

news.ycombinator.com

51–60 of 100 posts

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

#51

You may be relived to know that Unix epoch time does not have this problem. But you may also be horrified to know why. First, epoch seconds are not the numbers of seconds since 1970/01/01. This is a lie we tell to children. Rather, epoch seconds are the number of days since 1970/01/01 * 86400 plus the number of seconds since midnight. Leap seconds, to epoch time, don't exist. Or maybe they are double counted. Or mayb…

Yes, it's wrong. But we have also agreed to all be wrong in the same way. Except during the specific day that we are wrong in different ways.

Correction: We are mostly right, most of the time, but wrong in ways most people don't notice except if they try to talk while everyone is wrong.

Clarification: Human perception of time is not understandable, and the machine abstraction even less so.

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

#52

You may be relived to know that Unix epoch time does not have this problem. But you may also be horrified to know why. First, epoch seconds are not the numbers of seconds since 1970/01/01. This is a lie we tell to children. Rather, epoch seconds are the number of days since 1970/01/01 * 86400 plus the number of seconds since midnight. Leap seconds, to epoch time, don't exist. Or maybe they are double counted. Or mayb…

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: Every day has 86400 SI seconds, and we slowly go out of sync with the sun. That's TAI.

not 1, 2, 3: We use SI seconds and keep in sync with the sun +/- 1 second, but need to add/drop seconds occasionally. That's UTC.

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

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

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

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

#53
post #13

Earlier quoted context omitted.

The less brilliant thing about the smear is that if your ntpd syncs from smeared and unsmeared servers, the results aren't great. It would have been better if they would have kept the time on the wire accurate or added mandatory protocol stuff to avoid confusing things for ntpds configured to different leap second handling.

if you need below 1 millisecond time accuracy, probably you know what you are doing and you wont mix NTP servers (and I think you need PTP for that)

Until you work in financial markets and you want to measure latency vs a bunch of other servers you don't own, all of whom pick different smears (and some of whom aren't sure in advance which smears).

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

#54
post #14

I wonder how many systems actually care? I presume the core NTP servers handle this well, and most systems just feed off of that? GPS satellites probably handle it well too, but maybe some consumer or even industrial GPS receivers don't? Maybe some trading systems? I don't think crypto systems care too much.

I wonder if there's things that run 24/7 and need to be monitored.. e.g. if you have oil flowing through some pipeline at 100 liters/second, one particular minute will have 6100 liters, and someone will want to get paid for that 100 extra liters. But the meter/reporting tool would say "Well, we measure every second, and the meter reported a constant rate of 100 liter/second, and as we know we have 60 seconds in a min…

Now imagine blood pump during surgery.

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

#55
post #32

Earlier quoted context omitted.

I wonder if there's things that run 24/7 and need to be monitored.. e.g. if you have oil flowing through some pipeline at 100 liters/second, one particular minute will have 6100 liters, and someone will want to get paid for that 100 extra liters. But the meter/reporting tool would say "Well, we measure every second, and the meter reported a constant rate of 100 liter/second, and as we know we have 60 seconds in a min…

I once worked with smart meters for electricity consumption that do run 24/7. Leap seconds were not an issue but we had a very similar one now that I think about it: DST shenanigans! Like how much time is there between 2 and 3 am? Usually one hour, but sometimes 2 and also sometimes 0. It looks simple at first but it creates a lot of edge cases that your business logic now needs to handle and we had a fairly complex…

I can relate:

My son is born at 02h30 right DST change time.

It tooks 3 f*cking days to get his birth registered in the Hospital new birth registration system.

The hospital (at the time) just got digitalized and most systems where not able to agree if he was born after or before DST changes.

PS: I guess he is born fated to be a software QA later on.

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

#56
post #54

Earlier quoted context omitted.

I wonder if there's things that run 24/7 and need to be monitored.. e.g. if you have oil flowing through some pipeline at 100 liters/second, one particular minute will have 6100 liters, and someone will want to get paid for that 100 extra liters. But the meter/reporting tool would say "Well, we measure every second, and the meter reported a constant rate of 100 liter/second, and as we know we have 60 seconds in a min…

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.

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

#57
post #53

Earlier quoted context omitted.

if you need below 1 millisecond time accuracy, probably you know what you are doing and you wont mix NTP servers (and I think you need PTP for that)

Until you work in financial markets and you want to measure latency vs a bunch of other servers you don't own, all of whom pick different smears (and some of whom aren't sure in advance which smears).

financial markets dont trade when the smears happen (NYE)

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

#58
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 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 seconds are harder as they require you to reason about a clock that includes a 60th second but systems view negative leap seconds as if nothing happened for an entire second.

Now there are some cases where this runs into issues. If you have jobs that fire off based on the time then you can get jobs running a second early. Normally this shouldn't be a problem but in some cases this could result in contention of resources.

You could also accidentally trigger watchdogs but any watchdog worth its salt will use a real timer not wall time.

But overall negative leap seconds are way easier as they are still monotonically increasing and don't require downstream systems even understanding the concept of a leap second in the first place.

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

#59
post #36
post #3

Systems are absolutely not ready. Leap seconds are a bad idea and negative leap seconds are worse. Just don't do it and let the drift cancel out.

Explain why negative leap seconds are worse? Intuitively it seems like normal leap seconds would cause way more issues, or at least not more.

I am not an expert in Time systems but I imagine the problem is similar to daylight savings problems. With a leap second it's like putting the clocks forward an hour. With daylight savings, In your time series database you suddenly go from 0059 to 0200. 0100-0159 are missing, but that's fine. Most systems are fine with missing data, because we assume there will be occasional outages and such

When you go the other direction there's a potential problem. You have records with times from 0100-0159, then the daylight savings shift happens and you repeat 0100-0159. Now you have records with (apparently) duplicate timestamps.

I think it's probably the same problem with leap seconds and negative leap seconds, but I'm not 100% sure

Post reply on HN