4 ms·

Applying a negative second to a fleet is a solved problem, using the "leap smear" technique by Google. https://developers.google.com/time/smear https://develope

Applying a negative second to a fleet is a solved problem, using the "leap smear" technique by Google. https://developers.google.com/time/smear https://developers.google.com/time/smear Applying it to millions of individual servers with different OSes? I'll make the popcorn.

ncmncm 5y ago
Leap smear is itself an overwhelmingly bigger problem than a leap second. A leap second is over in a second. With leap smear you are out of sync with the rest of the world for many hours. And, there are at least three different leap smear schemes I know of: a massive judgment failure that happens again and again. The sensible alternative would be to eliminate leap seconds entirely for a few decades, and maybe stage a leap minute, eventually, or a leap hour in some far-off century, or never. It doesn't matter if the sun is ever exactly overhead at noon, because it isn't anyway, almost everywhere.
- toast0 5y ago
  > And, there are at least three different leap smear schemes I know of: a massive judgment failure that happens again and again. There's also the exciting version where some of your time servers do it one way, and some do another; you could probably pick two traditional servers, and then one of each of the others and have a really terrible day. From experience with a setup where 4 servers were traditional and one was smeared, there was a lot of variation in time; but thankfully my systems weren't relying on time measured on different servers to be very consistent. IMHO, leap smear probably should have been done with standard time on the wire, and the host agent doing the smear. But that would be more effort than doing it on the time servers, so there you go.
- StefanKarpinski 5y ago
  If I've learned one thing about dealing with exceptional events, it's that the less often they happen, the less likely you are to handle them well. Switching from leap seconds every few years to leap minutes every century, pretty much guarantees we'll screw it up. But maybe that's ok? Y2K was a fat nothingburger, after all the fuss.
  - an1sotropy 5y ago
    It's a little like a public health success: if done right, the worst that happens is that people have to prepare, and people complain about it, but disasters are avoided. Pre-Y2K there was a lot of fuss and hand-wringing, but there was also a lot of software development that happened to ensure that Y2K would not be a disaster. So then when Y2K rolled around the preparations mostly worked. My first programming job in high school was over-hauling a (mainframe-hosted) code base for handling lab data at a hospital. This was in the mid-90's; before most of the Y2K fuss had started. Without my work, pee and poo samples would be time traveling from the late Victorian era. You're welcome.
  - bee_rider 5y ago
    Push it out to a century, and then hope we have the ability to slightly accelerate the planet by then?
  - jonas21 5y ago
    Y2K was a fat nothingburger, because of all the fuss. Millions of person-years and $300 billion were spent to avert disaster - and it worked! But then all anyone ever sees is that nothing went wrong, and they assume it was nothing to begin with.
  - wmf 5y ago
    That's why we should eliminate leap seconds/minutes/hours and just change time zone definitions to keep the sun overhead near noon.
    - StefanKarpinski 5y ago
      Is the concept that UTC would become "detached" from a particular location on Earth and the offset of time zones relative to UTC would change over time (very infrequently since it would take on the order of a millenium for a time zone to shift by half an hour).
      - wmf 5y ago
        Exactly.
- fennecfoxen 5y ago
  > a leap hour in some far-off century Just change your time zone offsets at that point, honestly.
- zamadatix 5y ago
  It's not particularly interesting to be out of sync with the rest of the world, you always are and messages to/from external entities are even more so constantly. When it is interesting is when the thing you are doing is a function of time e.g. GPS or locked-step systems spanning geographic regions or so on. In almost all of those cases you're probably well used to dealing with time problems that are a bigger pain than a leap second. For those that aren't hiding the leap second and being off by slightly more than usual for a bit is probably better than hoping everyone can be prepared to suddenly care a lot about handling time oddities for one second every year (or century as you propose).
  - ncmncm 5y ago
    "Or never. Is never good for you?"
- vinkelhake 5y ago
  > A leap second is over in a second. The problem isn't one where you hold your breath and squeeze your eyes shut for a second while the unpleasantness passes. The problem is when you have tons of code running and you don't know exactly how it'll deal with this very rare event. If you're faced with an upcoming leap second there are various ways of dealing with it. One way is to do an audit of the code and hope that you can verify the most important parts. Another way is to smear and hope that most programs won't be negatively affected by reported seconds being 0.00001s off. There are other options, but I don't think there's an "obviously correct way".
  - throw0101a 5y ago
    > Another way is to smear and hope that most programs won't be negatively affected by reported seconds being 0.00001s off. > There are other options, but I don't think there's an "obviously correct way". Well, there are ways that following reality more and less. There are also ways that have legal traceability to time sources in some regulated industries.
- tvb 5y ago
  Only a positive leap second is “over in a second”. A negative leap second is essentially “over before it starts”. This asymmetry is an opportunity for code to implement UTC incorrectly. Another issue is that a positive leap second cannot be represented using time_t-like representations. But at least every time_t value maps to a UTC time. By contrast a negative leap second, should one occur, will cause a permanent illegal time_t value that has no existence in UTC. Checking for that illegal value in every piece of code that uses time_t values will not be fun.
  - Dylan16807 5y ago
    > By contrast a negative leap second, should one occur, will cause a permanent illegal time_t value that has no existence in UTC. Checking for that illegal value in every piece of code that uses time_t values will not be fun. Positive leap seconds, when translated into a dumb format and back, can be off by a second and won't round trip properly. Negative leap seconds, when translated out of a dumb format and back, can be off by a second and won't round trip properly. Seems pretty close to me.
throw0101a 5y ago
> Applying it to millions of individual servers with different OSes? I'll make the popcorn. The FreeBSD folks test for this: * https://lists.freebsd.org/pipermail/freebsd-stable/2020-November/092837.html https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove... The kernel and ntpd are fine with it. Applications: ¯\_(ツ)_/¯
baud147258 5y ago
> I'll make the popcorn. Too late, your IoT-enabled microwave just crashed and can't heat up the kernels

ncmncm 5y ago

Leap smear is itself an overwhelmingly bigger problem than a leap second. A leap second is over in a second. With leap smear you are out of sync with the rest of the world for many hours. And, there are at least three different leap smear schemes I know of: a massive judgment failure that happens again and again. The sensible alternative would be to eliminate leap seconds entirely for a few decades, and maybe stage a leap minute, eventually, or a leap hour in some far-off century, or never. It doesn't matter if the sun is ever exactly overhead at noon, because it isn't anyway, almost everywhere.

toast0 5y ago
> And, there are at least three different leap smear schemes I know of: a massive judgment failure that happens again and again. There's also the exciting version where some of your time servers do it one way, and some do another; you could probably pick two traditional servers, and then one of each of the others and have a really terrible day. From experience with a setup where 4 servers were traditional and one was smeared, there was a lot of variation in time; but thankfully my systems weren't relying on time measured on different servers to be very consistent. IMHO, leap smear probably should have been done with standard time on the wire, and the host agent doing the smear. But that would be more effort than doing it on the time servers, so there you go.
StefanKarpinski 5y ago
If I've learned one thing about dealing with exceptional events, it's that the less often they happen, the less likely you are to handle them well. Switching from leap seconds every few years to leap minutes every century, pretty much guarantees we'll screw it up. But maybe that's ok? Y2K was a fat nothingburger, after all the fuss.
- an1sotropy 5y ago
  It's a little like a public health success: if done right, the worst that happens is that people have to prepare, and people complain about it, but disasters are avoided. Pre-Y2K there was a lot of fuss and hand-wringing, but there was also a lot of software development that happened to ensure that Y2K would not be a disaster. So then when Y2K rolled around the preparations mostly worked. My first programming job in high school was over-hauling a (mainframe-hosted) code base for handling lab data at a hospital. This was in the mid-90's; before most of the Y2K fuss had started. Without my work, pee and poo samples would be time traveling from the late Victorian era. You're welcome.
- bee_rider 5y ago
  Push it out to a century, and then hope we have the ability to slightly accelerate the planet by then?
- jonas21 5y ago
  Y2K was a fat nothingburger, because of all the fuss. Millions of person-years and $300 billion were spent to avert disaster - and it worked! But then all anyone ever sees is that nothing went wrong, and they assume it was nothing to begin with.
- wmf 5y ago
  That's why we should eliminate leap seconds/minutes/hours and just change time zone definitions to keep the sun overhead near noon.
  - StefanKarpinski 5y ago
    Is the concept that UTC would become "detached" from a particular location on Earth and the offset of time zones relative to UTC would change over time (very infrequently since it would take on the order of a millenium for a time zone to shift by half an hour).
    - wmf 5y ago
      Exactly.
fennecfoxen 5y ago
> a leap hour in some far-off century Just change your time zone offsets at that point, honestly.
zamadatix 5y ago
It's not particularly interesting to be out of sync with the rest of the world, you always are and messages to/from external entities are even more so constantly. When it is interesting is when the thing you are doing is a function of time e.g. GPS or locked-step systems spanning geographic regions or so on. In almost all of those cases you're probably well used to dealing with time problems that are a bigger pain than a leap second. For those that aren't hiding the leap second and being off by slightly more than usual for a bit is probably better than hoping everyone can be prepared to suddenly care a lot about handling time oddities for one second every year (or century as you propose).
- ncmncm 5y ago
  "Or never. Is never good for you?"
vinkelhake 5y ago
> A leap second is over in a second. The problem isn't one where you hold your breath and squeeze your eyes shut for a second while the unpleasantness passes. The problem is when you have tons of code running and you don't know exactly how it'll deal with this very rare event. If you're faced with an upcoming leap second there are various ways of dealing with it. One way is to do an audit of the code and hope that you can verify the most important parts. Another way is to smear and hope that most programs won't be negatively affected by reported seconds being 0.00001s off. There are other options, but I don't think there's an "obviously correct way".
- throw0101a 5y ago
  > Another way is to smear and hope that most programs won't be negatively affected by reported seconds being 0.00001s off. > There are other options, but I don't think there's an "obviously correct way". Well, there are ways that following reality more and less. There are also ways that have legal traceability to time sources in some regulated industries.
tvb 5y ago
Only a positive leap second is “over in a second”. A negative leap second is essentially “over before it starts”. This asymmetry is an opportunity for code to implement UTC incorrectly. Another issue is that a positive leap second cannot be represented using time_t-like representations. But at least every time_t value maps to a UTC time. By contrast a negative leap second, should one occur, will cause a permanent illegal time_t value that has no existence in UTC. Checking for that illegal value in every piece of code that uses time_t values will not be fun.
- Dylan16807 5y ago
  > By contrast a negative leap second, should one occur, will cause a permanent illegal time_t value that has no existence in UTC. Checking for that illegal value in every piece of code that uses time_t values will not be fun. Positive leap seconds, when translated into a dumb format and back, can be off by a second and won't round trip properly. Negative leap seconds, when translated out of a dumb format and back, can be off by a second and won't round trip properly. Seems pretty close to me.

throw0101a 5y ago

> Applying it to millions of individual servers with different OSes? I'll make the popcorn. The FreeBSD folks test for this: * https://lists.freebsd.org/pipermail/freebsd-stable/2020-November/092837.html https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove... The kernel and ntpd are fine with it. Applications: ¯\_(ツ)_/¯

baud147258 5y ago

> I'll make the popcorn. Too late, your IoT-enabled microwave just crashed and can't heat up the kernels