29 ms·

Hate leap seconds? Imagine a negative one

adolph 5y ago
This is a fascinating read. If the Earth speeds up enough, we might find ourselves pondering over the possibility of a negative leap second. According to the Time and Date folks [0], a day in 2021 is averaging about 0.2ms faster than the 84600 atomic seconds per day, ~70ms/year, so at most 14 years of this would put us over the threshold (super unlikely). In reality, we don’t have to speed up a full 1000ms of rotation speed because there was always a fractional difference in UT1-UTC. https://www.timeanddate.com/time/earth-faster-rotation.html https://www.timeanddate.com/time/earth-faster-rotation.html
gamache 5y ago
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).
  - 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
fanf2 5y ago
Since that was published, the earth has been slowing down gradually. I keep a casual eye on IERS Bulletin A, which has the latest earth rotation observations, predictions for the next year, and a simple formula for longer-term estimates. https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html https://www.iers.org/IERS/EN/Publications/Bulletins/bulletin... The line I look at is UT1-UTC = -0.1204 + 0.00020 (MJD - 59593) - (UT2-UT1) which gives the current value of UT1-UTC (if -0.1204 grows to more than about +0.5 then we need a negative leap second) and the estimated long-term difference between earth’s rotation and 24x60x60 seconds (0.20 ms fast was up to 0.26 ms fast a few months ago). Actually, I have some code that looks at Bulletin A for me, https://github.com/fanf2/bulletin-a https://github.com/fanf2/bulletin-a which until recently was estimating that the next leap second would be a negative leap second in about 2028/9. But now its guess is receding into the future past 2030. I have a few tweet threads on this topic, which you can find via https://twitter.com/fanf/status/1478767806187552776 https://twitter.com/fanf/status/1478767806187552776 with some clicky-clicky to dig the older ones out of twitter’s delightful user interface. See also https://news.ycombinator.com/item?id=25145870 https://news.ycombinator.com/item?id=25145870 for some previous discussion here on this topic. So nothing dramatic is likely to happen any time soon, though the current situation is quite weird.
- d0mine 5y ago
  There is Python script https://github.com/zed/leap-second-client/ https://github.com/zed/leap-second-client/
- kelnos 5y ago
  I'm a little confused: if you look at the updated version of the same graph from the article (https://datacenter.iers.org/singlePlot.php?plotname=BulletinA_All-UT1-UTC&id=6 https://datacenter.iers.org/singlePlot.php?plotname=Bulletin...), it shows a continuation of the results of the speeding-up behavior, a positive slope on the UT1-UTC graph. Or am I misinterpreting things?
  - fanf2 5y ago
    I was mostly talking about the slope of those charts: the line is still going upwards, but more slowly. The seasonal effects (the regular lumps) are large so it is hard to tell from the graphs what the long term trend is. My guesses are based on the IERS estimate for what happens after the detailed predictions in Bulletin A, and their charts don’t go that far into the future.
civilized 5y ago
Now we're going to have "lies programmers believe about time": 1. Seconds in one time system last the same amount of time as seconds in another time system 2. Seconds in the same time system last the same amount of time as each other 3. Time numbers are strictly increasing - the same time number can't happen again 4. [etc, kill me]
- karmakurtisaani 5y ago
  Just wait until we reach the proper space age and start traveling at speeds close to the speed of light. Taking into account the relativistic effects is going make more than a few coders switch carees to organic farming.
  - nradov 5y ago
    GPS satellite designers already have to account for clock skew due to relativistic effects. A nice little real world confirmation of the theory.
  - monocasa 5y ago
    Luckily clock skew already happens and is handled more or less by the current systems. The difference between the system moving at relativistic speeds versus a crystal being slightly out of spec add up to the same result. Incorrect number of ticks for a given proper time interval. That's part of the genius of Leslie Lamport, embracing the fact that your distributed clocks aren't consistent, so start looking at effects through distributed systems from a light cone perspective just like you do with relativity.
    - willis936 5y ago
      Clock skew is in error. Relativistic time dilation is not. Both clocks will be right and disagree. You can't escape answering the question: do I care about the time elapsed at home or the time elapsed here?
      - kuschku 5y ago
vbezhenar 5y ago
I don't understand why do we need to have leap seconds. Even if time on Earth moves few minutes back, nobody would notice but astronomers. If time moves one hour back, just change your local zone offset, it happens all the time anyway, and that's about it. It makes time calculations unreasonably complex without any benefit.
- FabHK 5y ago
  Pick any two: 1. 86400 seconds a day 2. SI seconds 3. Noon synced up with the sun With UTC, we drop 1. With UT1, we drop 2. With TAI, we drop 3. Maybe we should have gone with TAI, or with UT1 - I think that's what Julia does, sort of: https://docs.julialang.org/en/v1/stdlib/Dates/#footnote-1 https://docs.julialang.org/en/v1/stdlib/Dates/#footnote-1
  - mavhc 5y ago
    Yep, just use TAI, you're already converting time to show it locally, so no problem also including leap seconds in that conversion
  - bumbledraven 5y ago
    Using TAI was also djb's solution to the problem. https://cr.yp.to/proto/utctai.html https://cr.yp.to/proto/utctai.html
- umvi 5y ago
  > I don't understand why do we need to have leap seconds. Even if time on Earth moves few minutes back, nobody would notice but astronomers. Right, and nobody's stopping you from using a sundial instead of a GPS watch if you don't care about high precision timekeeping. And if you do care about high precision timekeeping but hate leap seconds, you can use International Atomic Time (TAI). It all comes down to standardization. You might enjoy reading this: https://www.nist.gov/pml/time-and-frequency-division/nist-time-frequently-asked-questions-faq https://www.nist.gov/pml/time-and-frequency-division/nist-ti... Basically, standardization is hard. Not just for time, but any measurement (weight, length, etc). How do you absolutely guarantee that an airplane part made in France and the same airplane part made in Brazil are exactly the same dimensions/weight? You need standards. And those standards have slightly changed over time in an effort to achieve higher consistency/future-proofing. Time is especially difficult because gravity and speed affect time thanks to relativity. So how can you come up with a universally agreed upon definition of "one second"? The current best solution we have is to take a weighted average of 300+ atomic clocks. That's how we define TAI, and by extension, the second. However, people expect noon to be "the time when the sun is at its highest point in the sky". Leap seconds are used to make non-TAI time systems align exactly with the rotation of the earth. Without leap seconds, your local day will slowly drift until (millennia later) "noon" is happening in the middle of the night. And without leap years (which align the planet's orbit around the sun) your seasons will slowly drift for the same reason.
black6 5y ago
> It’s important to know that there are exactly 86400 (246060) UT1 seconds in a UT1 day. If the rotation of the Earth speeds up/slows down, the definition of a UT1 second changes since the number of seconds in a day is constant. I recently took an introductory Latin course and learned that ancient Roman time operated on the same principle. As the days got longer in the summer, so did the absolute length of time encompassed by an hour. Hard to make a sundial to automatically compensate, I imagine.
- bonzini 5y ago
  I don't remember the details but it's actually just as easy. They're called unequal hours, Babylonian hours or Italic hours. More precisely the difference between two sunrises or two sunsets was 24 hours, so the hours were longer in winter and spring as days get longer, and shorter in summer and fall as days get shorter.
- fanf2 5y ago
  A sundial measures the angle between a point on the surface of the earth, the centre of rotation of the earth, and the sun. Because the earth rotates at a constant-ish speed, a sundial naturally shows equal hours. It is possible, but tricky, to make an unequal-hours sundial: https://www.cl.cam.ac.uk/~fhk1/Sundials/Newnham/write-up.pdf https://www.cl.cam.ac.uk/~fhk1/Sundials/Newnham/write-up.pdf https://www.cl.cam.ac.uk/~fhk1/Sundials/Newnham/article01.pdf https://www.cl.cam.ac.uk/~fhk1/Sundials/Newnham/article01.pd... https://www.cl.cam.ac.uk/~fhk1/Sundials/Newnham/article02.pdf https://www.cl.cam.ac.uk/~fhk1/Sundials/Newnham/article02.pd... https://www.cl.cam.ac.uk/~fhk1/Sundials/Selwyn/Selwyn.pdf https://www.cl.cam.ac.uk/~fhk1/Sundials/Selwyn/Selwyn.pdf
beeforpork 5y ago
A negative leap second would be a fun experiment. E.g. in Germany, the atomic radio clock signal DCF77 does have a bit to announce a positive leap second, but it has no way of announcing a negative leap second. https://en.wikipedia.org/wiki/DCF77 https://en.wikipedia.org/wiki/DCF77 Now, cheap DCF77 clocks (e.g., alarm clocks) don't care about the leap second bit anyway, but they will just adjust a few minutes later during normal resync. And they will do so just fine with a negative leap second. But some clocks, most probably those hidden in industrial systems, controllers, etc., may need to stay exact, and I am sure it's fun to find out which systems really care and will then fail and in what ways. :-) Interestingly, the Japanese and the British atomic radio clock signals can do negative leap seconds: https://en.wikipedia.org/wiki/JJY https://en.wikipedia.org/wiki/JJY https://en.wikipedia.org/wiki/Time_from_NPL_(MSF) https://en.wikipedia.org/wiki/Time_from_NPL_(MSF) For WWVB, whether negative leap seconds are supported seems to depend on whether amplitude or phase shift modulation is used.
- fanf2 5y ago
  It is a curious fact that UTC is specified by the ITU in recommendation TF.460 https://www.itu.int/rec/R-REC-TF.460-6-200202-I/en https://www.itu.int/rec/R-REC-TF.460-6-200202-I/en which also includes a specification for how radio time broadcasts should be formatted. I don’t know if any time signals actually use that format, tho. That part of the ITU used to be CCIR, the international consultative committee for radio, which goes a little way to explaining it, but it is still strange that it isn’t the responsibility of the IAU, IERS, or SI.
  - sla29970 5y ago
    Strange is what they said just after the CCIR incepted leap seconds at the SI subcommittee in charge of the subject: "The CCIR may have overstepped its remit in defining the UTC" and "The process that led to UTC may have been illogical, but it was effective"
- tvb 5y ago
  DCF77 has a leap second warning bit. PTB says it is up to the user to know if it positive or negative. If a clock blindly assumes it is a positive leap that’s an error in the design of the clock. This is not ideal. Likewise WWVB has a leap second warning bit. But it includes a UT1 sign bit so the user can know if the leap will be positive or negative. This design is fine and any WWVB clock or software can properly handle positive or negative leap seconds. This is true for both the amplitude and the phase modulation formats.
champtar 5y ago
Why are we adjusting when after 100 years clock would be less than 1 min off. We should deprecate UTC and just use TAI, ~40s difference right now.
- deleted 5y ago
  [deleted]
- layer8 5y ago
  If we don't correct time-keeping to correspond to earth's rotation, their difference will increase roughly quadratically. Here is a table with estimates of when which delta (DUTC) will be reached: https://www.ucolick.org/~sla/leapsecs/dutc.html#dutctable https://www.ucolick.org/~sla/leapsecs/dutc.html#dutctable
  - chillacy 5y ago
    I found this section very interesting: > TAI is a statistical timescale which is produced at the BIPM by combining the reports from many atomic clocks around the world. Anyone who wants to find out what TAI it is now must mark the time with some local clock that contributes to TAI. Then some weeks after now when all clocks have been combined the difference between the local clock and TAI will be known. At that point it can be said what TAI it was at the moment of interest. > There are several interesting features here. First of all, before 1977 the clocks contributing to TAI were not corrected for the gravitational redshift. Because most clocks are above sea level they tick faster than TAI should tick. Through the mid-1980s there is an annual wobble due to seasonal environmental changes at some of the clock sites. In 1995 a CCTF working group deemed that the clock frequencies should be corrected for thermal radiation, and the CIPM affirmed this in 1997. The steering of TAI to the corrected frequency occurred over three years from 1995 to 1998, and the final levelling of the curve over those years indicates that the frequency of TAI is now consistent with cesium atoms at 0 Kelvin. Basically even with TAI there are all sorts of time deviations as an artifact of history.
somishere 5y ago
I'm actually fascinated by the climate change angle here. While it's already clear that our inability to tackle the climate crisis is having a physical, cultural and mental effect on our way of life .. a temporal one is something I don't think a lot of people have considered.
timando 5y ago
Is it possible to configure my computer to run on TAI and then use the timezone to say that I'm TAI+10:00:37. When a leap second happens, treat it as a DST transition.
- wglb 5y ago
  Well, you can at least get UT1: https://www.nist.gov/pml/time-and-frequency-division/time-services/ut1-ntp-time-dissemination https://www.nist.gov/pml/time-and-frequency-division/time-se...
rvnx 5y ago
I'm not sure why people are creating themselves problem ? UTC to be defined as the norm as it's the most stable, and those who wants to use UT1 for space / solar-related usage can use it and drift-away from UTC and that's it ?
lazyant 5y ago
Martin Kleppmann, author of "Designing Data Intensive Applications" talks about this in his excellent video series (skip to 14:30 for negative leap seconds etc) https://www.youtube.com/watch?v=FQ_2N3AQu0M&list=PLeKd45zvjcDFUEv_ohr_HdUFe97RItdiB&index=8 https://www.youtube.com/watch?v=FQ_2N3AQu0M&list=PLeKd45zvjc...
hffftz 5y ago
newpavlov 5y ago
FYI you can find an extensive discussion of this article on Reddit: https://www.reddit.com/r/programming/comments/s2mij2/ https://www.reddit.com/r/programming/comments/s2mij2/

This is a fascinating read. If the Earth speeds up enough, we might find ourselves pondering over the possibility of a negative leap second. According to the Time and Date folks [0], a day in 2021 is averaging about 0.2ms faster than the 84600 atomic seconds per day, ~70ms/year, so at most 14 years of this would put us over the threshold (super unlikely). In reality, we don’t have to speed up a full 1000ms of rotation speed because there was always a fractional difference in UT1-UTC. https://www.timeanddate.com/time/earth-faster-rotation.html https://www.timeanddate.com/time/earth-faster-rotation.html

gamache 5y ago

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).
- 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

fanf2 5y ago

Since that was published, the earth has been slowing down gradually. I keep a casual eye on IERS Bulletin A, which has the latest earth rotation observations, predictions for the next year, and a simple formula for longer-term estimates. https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html https://www.iers.org/IERS/EN/Publications/Bulletins/bulletin... The line I look at is UT1-UTC = -0.1204 + 0.00020 (MJD - 59593) - (UT2-UT1) which gives the current value of UT1-UTC (if -0.1204 grows to more than about +0.5 then we need a negative leap second) and the estimated long-term difference between earth’s rotation and 24x60x60 seconds (0.20 ms fast was up to 0.26 ms fast a few months ago). Actually, I have some code that looks at Bulletin A for me, https://github.com/fanf2/bulletin-a https://github.com/fanf2/bulletin-a which until recently was estimating that the next leap second would be a negative leap second in about 2028/9. But now its guess is receding into the future past 2030. I have a few tweet threads on this topic, which you can find via https://twitter.com/fanf/status/1478767806187552776 https://twitter.com/fanf/status/1478767806187552776 with some clicky-clicky to dig the older ones out of twitter’s delightful user interface. See also https://news.ycombinator.com/item?id=25145870 https://news.ycombinator.com/item?id=25145870 for some previous discussion here on this topic. So nothing dramatic is likely to happen any time soon, though the current situation is quite weird.

d0mine 5y ago
There is Python script https://github.com/zed/leap-second-client/ https://github.com/zed/leap-second-client/
kelnos 5y ago
I'm a little confused: if you look at the updated version of the same graph from the article (https://datacenter.iers.org/singlePlot.php?plotname=BulletinA_All-UT1-UTC&id=6 https://datacenter.iers.org/singlePlot.php?plotname=Bulletin...), it shows a continuation of the results of the speeding-up behavior, a positive slope on the UT1-UTC graph. Or am I misinterpreting things?
- fanf2 5y ago
  I was mostly talking about the slope of those charts: the line is still going upwards, but more slowly. The seasonal effects (the regular lumps) are large so it is hard to tell from the graphs what the long term trend is. My guesses are based on the IERS estimate for what happens after the detailed predictions in Bulletin A, and their charts don’t go that far into the future.

civilized 5y ago

Now we're going to have "lies programmers believe about time": 1. Seconds in one time system last the same amount of time as seconds in another time system 2. Seconds in the same time system last the same amount of time as each other 3. Time numbers are strictly increasing - the same time number can't happen again 4. [etc, kill me]

karmakurtisaani 5y ago
Just wait until we reach the proper space age and start traveling at speeds close to the speed of light. Taking into account the relativistic effects is going make more than a few coders switch carees to organic farming.
- nradov 5y ago
  GPS satellite designers already have to account for clock skew due to relativistic effects. A nice little real world confirmation of the theory.
- monocasa 5y ago
  Luckily clock skew already happens and is handled more or less by the current systems. The difference between the system moving at relativistic speeds versus a crystal being slightly out of spec add up to the same result. Incorrect number of ticks for a given proper time interval. That's part of the genius of Leslie Lamport, embracing the fact that your distributed clocks aren't consistent, so start looking at effects through distributed systems from a light cone perspective just like you do with relativity.
  - willis936 5y ago
    Clock skew is in error. Relativistic time dilation is not. Both clocks will be right and disagree. You can't escape answering the question: do I care about the time elapsed at home or the time elapsed here?
    - kuschku 5y ago

vbezhenar 5y ago

I don't understand why do we need to have leap seconds. Even if time on Earth moves few minutes back, nobody would notice but astronomers. If time moves one hour back, just change your local zone offset, it happens all the time anyway, and that's about it. It makes time calculations unreasonably complex without any benefit.

FabHK 5y ago
Pick any two: 1. 86400 seconds a day 2. SI seconds 3. Noon synced up with the sun With UTC, we drop 1. With UT1, we drop 2. With TAI, we drop 3. Maybe we should have gone with TAI, or with UT1 - I think that's what Julia does, sort of: https://docs.julialang.org/en/v1/stdlib/Dates/#footnote-1 https://docs.julialang.org/en/v1/stdlib/Dates/#footnote-1
- mavhc 5y ago
  Yep, just use TAI, you're already converting time to show it locally, so no problem also including leap seconds in that conversion
- bumbledraven 5y ago
  Using TAI was also djb's solution to the problem. https://cr.yp.to/proto/utctai.html https://cr.yp.to/proto/utctai.html
umvi 5y ago
> I don't understand why do we need to have leap seconds. Even if time on Earth moves few minutes back, nobody would notice but astronomers. Right, and nobody's stopping you from using a sundial instead of a GPS watch if you don't care about high precision timekeeping. And if you do care about high precision timekeeping but hate leap seconds, you can use International Atomic Time (TAI). It all comes down to standardization. You might enjoy reading this: https://www.nist.gov/pml/time-and-frequency-division/nist-time-frequently-asked-questions-faq https://www.nist.gov/pml/time-and-frequency-division/nist-ti... Basically, standardization is hard. Not just for time, but any measurement (weight, length, etc). How do you absolutely guarantee that an airplane part made in France and the same airplane part made in Brazil are exactly the same dimensions/weight? You need standards. And those standards have slightly changed over time in an effort to achieve higher consistency/future-proofing. Time is especially difficult because gravity and speed affect time thanks to relativity. So how can you come up with a universally agreed upon definition of "one second"? The current best solution we have is to take a weighted average of 300+ atomic clocks. That's how we define TAI, and by extension, the second. However, people expect noon to be "the time when the sun is at its highest point in the sky". Leap seconds are used to make non-TAI time systems align exactly with the rotation of the earth. Without leap seconds, your local day will slowly drift until (millennia later) "noon" is happening in the middle of the night. And without leap years (which align the planet's orbit around the sun) your seasons will slowly drift for the same reason.

black6 5y ago

> It’s important to know that there are exactly 86400 (246060) UT1 seconds in a UT1 day. If the rotation of the Earth speeds up/slows down, the definition of a UT1 second changes since the number of seconds in a day is constant. I recently took an introductory Latin course and learned that ancient Roman time operated on the same principle. As the days got longer in the summer, so did the absolute length of time encompassed by an hour. Hard to make a sundial to automatically compensate, I imagine.

bonzini 5y ago
I don't remember the details but it's actually just as easy. They're called unequal hours, Babylonian hours or Italic hours. More precisely the difference between two sunrises or two sunsets was 24 hours, so the hours were longer in winter and spring as days get longer, and shorter in summer and fall as days get shorter.
fanf2 5y ago
A sundial measures the angle between a point on the surface of the earth, the centre of rotation of the earth, and the sun. Because the earth rotates at a constant-ish speed, a sundial naturally shows equal hours. It is possible, but tricky, to make an unequal-hours sundial: https://www.cl.cam.ac.uk/~fhk1/Sundials/Newnham/write-up.pdf https://www.cl.cam.ac.uk/~fhk1/Sundials/Newnham/write-up.pdf https://www.cl.cam.ac.uk/~fhk1/Sundials/Newnham/article01.pdf https://www.cl.cam.ac.uk/~fhk1/Sundials/Newnham/article01.pd... https://www.cl.cam.ac.uk/~fhk1/Sundials/Newnham/article02.pdf https://www.cl.cam.ac.uk/~fhk1/Sundials/Newnham/article02.pd... https://www.cl.cam.ac.uk/~fhk1/Sundials/Selwyn/Selwyn.pdf https://www.cl.cam.ac.uk/~fhk1/Sundials/Selwyn/Selwyn.pdf

beeforpork 5y ago

A negative leap second would be a fun experiment. E.g. in Germany, the atomic radio clock signal DCF77 does have a bit to announce a positive leap second, but it has no way of announcing a negative leap second. https://en.wikipedia.org/wiki/DCF77 https://en.wikipedia.org/wiki/DCF77 Now, cheap DCF77 clocks (e.g., alarm clocks) don't care about the leap second bit anyway, but they will just adjust a few minutes later during normal resync. And they will do so just fine with a negative leap second. But some clocks, most probably those hidden in industrial systems, controllers, etc., may need to stay exact, and I am sure it's fun to find out which systems really care and will then fail and in what ways. :-) Interestingly, the Japanese and the British atomic radio clock signals can do negative leap seconds: https://en.wikipedia.org/wiki/JJY https://en.wikipedia.org/wiki/JJY https://en.wikipedia.org/wiki/Time_from_NPL_(MSF) https://en.wikipedia.org/wiki/Time_from_NPL_(MSF) For WWVB, whether negative leap seconds are supported seems to depend on whether amplitude or phase shift modulation is used.

fanf2 5y ago
It is a curious fact that UTC is specified by the ITU in recommendation TF.460 https://www.itu.int/rec/R-REC-TF.460-6-200202-I/en https://www.itu.int/rec/R-REC-TF.460-6-200202-I/en which also includes a specification for how radio time broadcasts should be formatted. I don’t know if any time signals actually use that format, tho. That part of the ITU used to be CCIR, the international consultative committee for radio, which goes a little way to explaining it, but it is still strange that it isn’t the responsibility of the IAU, IERS, or SI.
- sla29970 5y ago
  Strange is what they said just after the CCIR incepted leap seconds at the SI subcommittee in charge of the subject: "The CCIR may have overstepped its remit in defining the UTC" and "The process that led to UTC may have been illogical, but it was effective"
tvb 5y ago
DCF77 has a leap second warning bit. PTB says it is up to the user to know if it positive or negative. If a clock blindly assumes it is a positive leap that’s an error in the design of the clock. This is not ideal. Likewise WWVB has a leap second warning bit. But it includes a UT1 sign bit so the user can know if the leap will be positive or negative. This design is fine and any WWVB clock or software can properly handle positive or negative leap seconds. This is true for both the amplitude and the phase modulation formats.

champtar 5y ago

Why are we adjusting when after 100 years clock would be less than 1 min off. We should deprecate UTC and just use TAI, ~40s difference right now.

deleted 5y ago
[deleted]
layer8 5y ago
If we don't correct time-keeping to correspond to earth's rotation, their difference will increase roughly quadratically. Here is a table with estimates of when which delta (DUTC) will be reached: https://www.ucolick.org/~sla/leapsecs/dutc.html#dutctable https://www.ucolick.org/~sla/leapsecs/dutc.html#dutctable
- chillacy 5y ago
  I found this section very interesting: > TAI is a statistical timescale which is produced at the BIPM by combining the reports from many atomic clocks around the world. Anyone who wants to find out what TAI it is now must mark the time with some local clock that contributes to TAI. Then some weeks after now when all clocks have been combined the difference between the local clock and TAI will be known. At that point it can be said what TAI it was at the moment of interest. > There are several interesting features here. First of all, before 1977 the clocks contributing to TAI were not corrected for the gravitational redshift. Because most clocks are above sea level they tick faster than TAI should tick. Through the mid-1980s there is an annual wobble due to seasonal environmental changes at some of the clock sites. In 1995 a CCTF working group deemed that the clock frequencies should be corrected for thermal radiation, and the CIPM affirmed this in 1997. The steering of TAI to the corrected frequency occurred over three years from 1995 to 1998, and the final levelling of the curve over those years indicates that the frequency of TAI is now consistent with cesium atoms at 0 Kelvin. Basically even with TAI there are all sorts of time deviations as an artifact of history.

somishere 5y ago

I'm actually fascinated by the climate change angle here. While it's already clear that our inability to tackle the climate crisis is having a physical, cultural and mental effect on our way of life .. a temporal one is something I don't think a lot of people have considered.

timando 5y ago

Is it possible to configure my computer to run on TAI and then use the timezone to say that I'm TAI+10:00:37. When a leap second happens, treat it as a DST transition.

wglb 5y ago
Well, you can at least get UT1: https://www.nist.gov/pml/time-and-frequency-division/time-services/ut1-ntp-time-dissemination https://www.nist.gov/pml/time-and-frequency-division/time-se...

rvnx 5y ago

I'm not sure why people are creating themselves problem ? UTC to be defined as the norm as it's the most stable, and those who wants to use UT1 for space / solar-related usage can use it and drift-away from UTC and that's it ?

lazyant 5y ago

Martin Kleppmann, author of "Designing Data Intensive Applications" talks about this in his excellent video series (skip to 14:30 for negative leap seconds etc) https://www.youtube.com/watch?v=FQ_2N3AQu0M&list=PLeKd45zvjcDFUEv_ohr_HdUFe97RItdiB&index=8 https://www.youtube.com/watch?v=FQ_2N3AQu0M&list=PLeKd45zvjc...

hffftz 5y ago

newpavlov 5y ago

FYI you can find an extensive discussion of this article on Reddit: https://www.reddit.com/r/programming/comments/s2mij2/ https://www.reddit.com/r/programming/comments/s2mij2/