[dead]
Ask HN: Are systems ready for the first negative leap second?
41–50 of 100 posts
Re: Ask HN: Are systems ready for the first negative leap second?
#42The 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.
Re: Ask HN: Are systems ready for the first negative leap second?
#43I'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 delive…
Re: Ask HN: Are systems ready for the first negative leap second?
#44I'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.
Re: Ask HN: Are systems ready for the first negative leap second?
#45I'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 delive…
> gettimeofday() should never be used to measure time And yet, even as somebody who has no idea what platform you're referring to, I can still guarantee you that gettimeofday() is used to measure time on that platform. This is how software works, unfortunately.
As per my linked blog post…
Re: Ask HN: Are systems ready for the first negative leap second?
#46I 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…
> 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 are already living many minutes off from the "actual" time at their precise location, in some cases even more than an hour. "Giving-up" implies that this is something important worth maintaining, where-as for the vast majority of people they gain nothing from leap seconds or even leap minutes. The most important thing for people is simply that everybody agrees on what time it is, which is easier when leap-Xs aren't done.
That said it's also probably true that a leap-hour would never actually happen, but that's not some big issue. By the time we got to the point that a leap-hour would make sense people would have already adjusted their habits and it probably wouldn't be worth it.
Re: Ask HN: Are systems ready for the first negative leap second?
#47Earlier 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?
If you're calculating time that a task took by subtracting two UTC datetimes instead of just using a monotonic timer or at least unix timestamps, you're doing it wrong either way
Re: Ask HN: Are systems ready for the first negative leap second?
#48You 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.
Re: Ask HN: Are systems ready for the first negative leap second?
#49Earlier quoted context omitted.
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…
> 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).
Re: Ask HN: Are systems ready for the first negative leap second?
#50Earlier quoted context omitted.
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…
> 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…
Indeed. On a long-enough timeline, people will adjust to whatever it is that the sun is doing regardless of what the clock on the wall says. That's the way it has always been.
So when we're talking about one second every once in awhile, I'm not sure that [effectively] giving up by adopting leap hours instead of leap seconds isn't the right option -- as long as we agree to do it uniformly.