Bypassing the problem
Clocks do not usually count the number 60 second, so some alternatives should be taken in this regard. Some possibilities are:
- Some Linux kernels implement a jump back from 1s, repeating the 59th second. For more information: Resolve Leap Second Issues in Red Hat Enterprise Linux ;
- Windows servers ignore the second 60, synchronizing again with the atomic clocks just after it passes. This means that they count twice the second 0 on July 1. For more information: How the Windows Time Service treats a leap second ,
- Some organizations including Amazon Web Services plan to split and spread the second extra for several hours, by making each second a little longer (the English term is "leap smear");
- If the clock does not connect to a synchronization system, it simply does not implement any kind of tuning for that.
Source: Look Before You Leap - The Coming Leap Second and AWS
Possible Complications
Many technological devices synchronize their clocks with an atomic clock. However, many of them have not been programmed to consider the possibility of the second extra happening, so when the system identifies it it has an unintended result, which can result in crashes of servers and consequently your services.
In 2012, Mozilla, Reddit, Foursquare, Yelp, LinkedIn and StumbleUpon, showed system crashes when the second extra was added. Google, which used the leap smear tactic, escaped unharmed.
This year some servers are expected to experience this problem again.
Source: Daily News - 'Leap second' coming up June 30 may cause computer system problems
Update: What were the damages of the second extra 2015?
Although AWS says it was not the fault of the second extra, its services were down for just over 40 minutes, but not as% of% as of 00:00 UTC
to 00:25
, leaving out of the air services like Slack, Netflix, Pinterest and thousands of other websites and services.
The news:
Between 5:25 PM and 6:07 PM PDT we have an Internet connectivity issue with a provider outside of our network which affected traffic from some end-user networks. The issue has been resolved and the service is operating normally.
The root cause of this issue was an external Internet service provider incorrectly accepting a set of routes for some AWS addresses from a third party who inadvertently advertised these routes. Providers should normally reject these routes by policy, but in this case the routes were accepted and propagated to other ISPs affecting some end-user's ability to access AWS resources. Once we identified the provider and third-party network, we took action to route this incorrect routing configuration. We have worked with this external Internet service provider to ensure that this does not reoccur.
Source: AWS Service Health Dashboard
According to them, it was the fault of external servers who incorrectly accepted a set of routes for some AWS addresses that were inadvertently advertised by third parties ... Was not that clear to you? Not for me either. The fact is that a lot of people are suspicious that the problem was yes of the second extra, although AWS says they do not.
Source: Mashable - Slack, Netflix, Pinterest crash and you can not blame the leap second