By adding a leap second when the UTC drifts 0.9 seconds from the Universal Time (UT1), or Astronomical Time, clocks that are synched with UTC effectively stop for one second to allow “the Earth the opportunity to catch up with atomic time,” according to timeanddate.com.
Leap seconds are announced and coordinated by the International Earth Rotation and Reference System Service (IERS) in Paris, France. Twenty-six leap seconds have been recorded, with the first taking place in 1972.
The most recent leap second took place on Saturday, December 31st, 2016, at 6:59:60pm, and the next is expected to occur sometime in 2018.
Why Leap Seconds Can Be Problematic for IT
Systems with code that hasn’t accounted for leap seconds can appear to be sending information from the future when attempting to sync with applications that have adjusted for the leap second. This can result in errors with tracking and reporting events, keeping replications up to date and in sync, determining the order of data operations, and more.
Google’s Leap Smear Available to Account for 2016 Leap Second
Google relies on a technique known as “smeared time,” or a leap smear, to avoid potential critical issues associated with leap seconds. For the 2016 Leap Second, Google announced it would let anyone use its NTP (Network Time Protocol) servers to help avoid issues.
Google’s NTP servers run clocks 0.0014 percent slower for 10 hours before the leap second and then do the same for 10 hours afterward to account for a leap second without disrupting applications and systems that depend on time synchronization.
Google’s NTP servers are freely available through the Google Public NTP service. By configuring network settings to utilize time.google.com as their NTP server, enterprises can ensure their systems and apps will be able to handle leap seconds. Google offers detailed instructions for utilizing leap smears for synchronizing systems.