On the 30th of June at 23:59:60 UTC there will be a leap second.
This will be the third one experienced by Google and the 26th recorded leap time. This is interesting in itself, but it can cause issues with systems that depend on the careful sequencing of events.
The issue is that for multi-node distributed systems, a one second jump can dramatically magnify time sync discrepancies between the nodes.
This could result in two events going into a database under the same time stamp or even the later one being recorded under an earlier time stamp, when in reality one follows another.
Google admits that most of its software wasn’t written to handle this and during the 2005 leap second the company faced a number of issues like this with its internal systems.
In order to counter this, the company will "smear" away the extra second. It is explained on the company’s blog: "During a 20-hour "smear window" centered on the leap second, we slightly slow all our servers’ system clocks (by approximately 14 parts per million). At the end of the smear window, the entire leap second has been added, and we are back in sync with civil time."
This will only apply to Virtual Machine that are running on Google Compute Engine as they are the only entities than can manually sync time.
Content from our partners
Google said: "The worst possible configuration during a leap second is to use a mixture of non-smearing and smearing NTP servers (or servers that smear differently): behavior will be undefined, but probably bad."
"If you run services on both Google Compute Engine and other providers that do not smear leap seconds, you should be aware that your services can see discrepancies in time during the leap second."
