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

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 maybe we smear them over 12 or 24 hours (but which 12 or 24 hours depends on whether you are Google, Microsoft, or Oracle; I can't even make this stuff up). The point is, it's not defined, and this means implementations do it differently.

A negative leap second might be easier though. The spec suggests (though lack of speaking) that a correct implementation will just skip it since number of seconds stays less than 86400 for that day. But of course the smear-organizations still smear it.

So what if you really want to know how many seconds were between two different epochs? Subtracting epoch seconds is wrong because you need to correct for the number of leap seconds between the two times.

And the smears.

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.

Google's proposal is a smear. [1] Most time servers do not use smear. No idea what behavior it may introduce in places where sub-second time is important. Curious if all these bugs [2] were fixed specifically to deal with going backwards.

[1] - https://developers.google.com/time/smear

[2] - https://rivassec.com/leap-second-chaos-2012.html

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.

Not responsible for those systems.

The last time this came up I thought “smearing” the second over the course of a day kind of solved the problem a discrete +/- 1 second suddenly appearing on the clocks.

If we have positive and negative leap seconds, why are we doing anything at all? 1 second forward, just to go 1 second back 10 years later…

Since the whole leap second system will be phased out by 2035 anyways I doubt that anyone will test it. No need to rock the boat over a second.

I'd say yes we are ready. gettimeofday() should never be used to measure time[1], but at least with a negative leap second it's monotonic.

We'll just get some poorly coded stuff claim that an operation took 1100ms instead of 100ms. Not great, but not -900ms.

Well, I say that, but per my link here F5 load balancers at least used to keep track of TCP connections using gettimeofday. And it's annoying that libpcap delivers metadata in wallclock time.

[1] https://blog.habets.se/2010/09/gettimeofday-should-never-be-...

I'm rooting for pure UTC never adjusted to actual sidereal days. Let me wake up at 1600 and go to sleep at 800, it's fine.

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.

Wasn't there a recent discussion here, where it was pointed out that leap seconds are about to be phased out in less than 10 years' time? I would be extremely surprised if a negative leap second was implemented before then, given that IERS already balked at doing that several years ago.

NTP.

By any other standard, most manually set clocks are up to a full minute off all the time.

The FreeBSD folks test their code for these things and it works:

* https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove...

Of course third-party userland code understanding what happens is another thing.

Don't systems regularly have this issue when they do time server syncs?

[dead]

[flagged]