|
|
|
|
|
by lucb1e
4006 days ago
|
|
This sounds rather exaggerated to me. 10% of the systems will have trouble with it? Perhaps during the leap second something will bug or look weird, but outside of that second I doubt it's even 1% that will have trouble recovering. Also, many systems don't even support the leap second, nothing will happen at all until they sync with time servers the next time and correct for the second. Many systems are off a second or so anyway. As a quick example, Javascript is not designed to handle leap seconds correctly, so I doubt we'll ever see the value 60 out of new Date().getSeconds(). Things will just be off by 1 second for a second. Edit: Another example from the Windows Time service: > The Windows Time service does not indicate the value of the Leap Indicator when the Windows Time service receives a packet that includes a leap second. [...] Therefore, after the leap second occurs, the NTP client that is running Windows Time service is one second faster than the actual time. This time difference is resolved at the next time synchronization. It will just be a second off and resynchronize next time. |
|
Also, not sure if any of the systems mentioned in the article run JS for critical server side code.