4 ms·

> A negative leap second would mean that our clocks skip one second, which could potentially create problems for IT systems. At least biggest cloud providers h

> A negative leap second would mean that our clocks skip one second, which could potentially create problems for IT systems. At least biggest cloud providers have already envisioned this [1]. > A negative leap second, if one were ever to occur, would be smeared by speeding up clocks over the 86,399 SI seconds from noon to noon. [1] https://developers.google.com/time/smear?hl=en https://developers.google.com/time/smear?hl=en

LeoPanthera 4y ago
Why is a leap smear necessary for skipping forwards? Unlike a typical leap second, which goes backwards, a forward jump doesn't repeat timestamps. The clock could literally just jump forwards a second and it would be fine.
- bpodgursky 4y ago
  This breaks down when you think of all the code that assumes 60 seconds in a minute: ONE_HOUR_AGO = 60*60 Apply that to the wrong hour and... oops.
  - LeoPanthera 4y ago
    Ah, so this is another "Falsehoods programmers believe about time" situation. https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...
    - Dylan16807 4y ago
      I wouldn't go as far as "falsehood". Leap seconds aren't inherent to timekeeping. It's easier to do without them, and a system like that isn't wrong.
      - LeoPanthera 4y ago
        > Leap seconds aren't inherent to timekeeping. Leap seconds are inherent to timekeeping based on the sun, which all civil time is. Without them, "midday" and "midnight" become undefined.
        Dylan16807 4y ago
        Civil time is based on time zones, and it will take thousands of years to have a meaningful drift in comparison to that. If we avoid the hubris of thinking that we know how clocks will be set hundreds of years in the future, then the error from lacking leap seconds is negligible. And it's not like allowing .9 seconds of drift is objectively correct either.
        LeoPanthera 4y ago
        The boundaries of time zones are defined with reference to a fixed line - the prime meridian. On the prime meridian, "midnight" is an important concept, marking the change of date. A second of drift is negligible, but a minute of drift pushes the boundaries of time zones sideways by 6086 feet at the equator.
        Dylan16807 4y ago
        > On the prime meridian, "midnight" is an important concept, marking the change of date. But having the average solar midnight match that very specific spot is not important. > A second of drift is negligible, but a minute of drift pushes the boundaries of time zones sideways by 6086 feet at the equator. Which doesn't matter when they're 60x that size wide. Especially when countries will shift an entire time zone for fun. A minute of drift is also negligible for civil time, as long as everyone is in sync, and we can't really predict the timekeeping future beyond that first minute of drift.
        naniwaduni 4y ago
        Civil timekeeping accepts error vs solar time of up to half an hour as table stakes, and routinely raises that by an hour or more. Leap seconds account for half a minute over half a century. You can get a legislature to change your time zone faster than the problem leap seconds purport to solve can become relevant.
      - defrost 4y ago
        You know what absolutey is inherent to imekeeping? * Drift between terresterial and sidereal time, * Drift between terresterial ground level (1G gravity mean 'surface') and orbiting satellite (eg: GPS time) * Differing frames of time reference best suited for different tasks. Common computer time server synced time is based on the nominal notion of "mean noontime" UTC .. or the rotation time of the earth to move from Greenwich "pointing at the sun" to again "point at the sun" (perhaps surprising to some NOT a full "360 degree" rotation as the earth has moved forward on its orbit). Myths about time that programmers should know is a good read .. eventually drift between systems must be addressed ( GPS sats use "epoch time" (local atomic clock ticks) lapsed "per week" and GPS recievers reconcile relativistic drift using broadcast corrections ). Any significant scientific data collection program (geophysics, astronomy) required the use of some form of "epoch time" with accurate local clocks not synced to UT | GMT | Zulu time servers. Your apparent desire to not deal with adjustments on the order of a second during your lifetime is simply pushing the problem down the road until it's a case of reconciling hours .. or even 11 days (as has already happened in history).
        Dylan16807 4y ago
        All those things are definitely important, and leap seconds don't help with any of them. > Your apparent desire to not deal with adjustments on the order of a second during your lifetime is simply pushing the problem down the road until it's a case of reconciling hours .. or even 11 days (as has already happened in history). An hour, or fraction of an hour, is significantly easier to reconcile. Even assuming we stick with the same system for that very large number of years.
        defrost 4y ago
        We've stuck with noon centred based timekeeping for two thousand odd years now, I suspect it'll remain that way for a few hundred years more. Fractions of hours require the same effort of understanding the issue that seconds do. Where it matters (my field) we use absolute lapsed seconds in a specific framework and don't rely on sync'ing to UTC.
        4y ago
    - bpodgursky 4y ago
      I don't really want to get into what code should or shouldn't have been written. When you are designing infrastructure to support millions of lines of existing code, you figure out what will break the least code, and you do it.
- fanf2 4y ago
  The main worry about a negative leap second is that we have never had one so we don’t know what surprising failure modes might turn up.
notatoad 4y ago
envisioned it and actually experienced it are different things though.

LeoPanthera 4y ago

Why is a leap smear necessary for skipping forwards? Unlike a typical leap second, which goes backwards, a forward jump doesn't repeat timestamps. The clock could literally just jump forwards a second and it would be fine.

bpodgursky 4y ago
This breaks down when you think of all the code that assumes 60 seconds in a minute: ONE_HOUR_AGO = 60*60 Apply that to the wrong hour and... oops.
- LeoPanthera 4y ago
  Ah, so this is another "Falsehoods programmers believe about time" situation. https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...
  - Dylan16807 4y ago
    I wouldn't go as far as "falsehood". Leap seconds aren't inherent to timekeeping. It's easier to do without them, and a system like that isn't wrong.
    - LeoPanthera 4y ago
      > Leap seconds aren't inherent to timekeeping. Leap seconds are inherent to timekeeping based on the sun, which all civil time is. Without them, "midday" and "midnight" become undefined.
      - Dylan16807 4y ago
        Civil time is based on time zones, and it will take thousands of years to have a meaningful drift in comparison to that. If we avoid the hubris of thinking that we know how clocks will be set hundreds of years in the future, then the error from lacking leap seconds is negligible. And it's not like allowing .9 seconds of drift is objectively correct either.
        LeoPanthera 4y ago
        The boundaries of time zones are defined with reference to a fixed line - the prime meridian. On the prime meridian, "midnight" is an important concept, marking the change of date. A second of drift is negligible, but a minute of drift pushes the boundaries of time zones sideways by 6086 feet at the equator.
        Dylan16807 4y ago
        > On the prime meridian, "midnight" is an important concept, marking the change of date. But having the average solar midnight match that very specific spot is not important. > A second of drift is negligible, but a minute of drift pushes the boundaries of time zones sideways by 6086 feet at the equator. Which doesn't matter when they're 60x that size wide. Especially when countries will shift an entire time zone for fun. A minute of drift is also negligible for civil time, as long as everyone is in sync, and we can't really predict the timekeeping future beyond that first minute of drift.
      - naniwaduni 4y ago
        Civil timekeeping accepts error vs solar time of up to half an hour as table stakes, and routinely raises that by an hour or more. Leap seconds account for half a minute over half a century. You can get a legislature to change your time zone faster than the problem leap seconds purport to solve can become relevant.
    - defrost 4y ago
      You know what absolutey is inherent to imekeeping? * Drift between terresterial and sidereal time, * Drift between terresterial ground level (1G gravity mean 'surface') and orbiting satellite (eg: GPS time) * Differing frames of time reference best suited for different tasks. Common computer time server synced time is based on the nominal notion of "mean noontime" UTC .. or the rotation time of the earth to move from Greenwich "pointing at the sun" to again "point at the sun" (perhaps surprising to some NOT a full "360 degree" rotation as the earth has moved forward on its orbit). Myths about time that programmers should know is a good read .. eventually drift between systems must be addressed ( GPS sats use "epoch time" (local atomic clock ticks) lapsed "per week" and GPS recievers reconcile relativistic drift using broadcast corrections ). Any significant scientific data collection program (geophysics, astronomy) required the use of some form of "epoch time" with accurate local clocks not synced to UT | GMT | Zulu time servers. Your apparent desire to not deal with adjustments on the order of a second during your lifetime is simply pushing the problem down the road until it's a case of reconciling hours .. or even 11 days (as has already happened in history).
      - Dylan16807 4y ago
        All those things are definitely important, and leap seconds don't help with any of them. > Your apparent desire to not deal with adjustments on the order of a second during your lifetime is simply pushing the problem down the road until it's a case of reconciling hours .. or even 11 days (as has already happened in history). An hour, or fraction of an hour, is significantly easier to reconcile. Even assuming we stick with the same system for that very large number of years.
        defrost 4y ago
        We've stuck with noon centred based timekeeping for two thousand odd years now, I suspect it'll remain that way for a few hundred years more. Fractions of hours require the same effort of understanding the issue that seconds do. Where it matters (my field) we use absolute lapsed seconds in a specific framework and don't rely on sync'ing to UTC.
        4y ago
  - bpodgursky 4y ago
    I don't really want to get into what code should or shouldn't have been written. When you are designing infrastructure to support millions of lines of existing code, you figure out what will break the least code, and you do it.
fanf2 4y ago
The main worry about a negative leap second is that we have never had one so we don’t know what surprising failure modes might turn up.

notatoad 4y ago

envisioned it and actually experienced it are different things though.