“Leap Smearing must not be used for public-facing NTP servers” - <a href="https://tools.ietf.org/html/draft-ietf-ntp-bcp-02" rel="nofollow">https://tools.ietf.org/html/draft-ietf-ntp-bcp-02</a>
> Instead of adding a single extra second to the end of the day, we'll run the clocks 0.0014% slower across the ten hours before and ten hours after the leap second, and “smear” the extra second across these twenty hours.<p>Holy leaping second, batman! Unilaterally being off by up to a half second from the rest of the world's clocks is a pretty aggressive step. I think I would have preferred to see a resolution made by an independent body on something this drastic.
I predicted this for leap smear a while back-- we have time sync because having systems with different times is a source of problems... logical fix: get them onto the same time.<p>Smear is a workaround for those who care about phase alignment but don't care about frequency error. ... and who don't need to exchange times with anyone else. This last point reduces the set to no one, since it can't extend to everyone (some parties care a lot more about frequency error than phase error!).<p>This circus is enhanced by NTP's inability to tell you what timebase it's using (or, god forbid, offsets between what its giving you and other timebases...)<p>It's going be especially awesome when NTP daemons with both smear and non-smear peers get both the smear frequency error AND get a leap second.<p>I for one welcome this great opportunity for an enhanced trash fire to help convince the world that we need to stop issuing leap seconds. (It's absurd-- causes tens of millions in disruption easily, -- and it would take 4000 years to even drift an hour off solar time, at which point timezones could be rotated if anyone really cared).
A lot of interesting geophysics in the unpredictable need for leap seconds. I mention Google's "smearing" approach here:<p><a href="http://arstechnica.com/science/2016/04/the-leap-second-because-our-clocks-are-more-accurate-than-the-earth/" rel="nofollow">http://arstechnica.com/science/2016/04/the-leap-second-becau...</a>
For people talking about Google unilaterally doing this, it has been common to smear the leap second for the last couple years. Usually companies do it internally by having their NTP servers skew time, either with Chrony or `ntpd -x`. Standards bodies have not been able to react quickly enough to the need to smear the leap second in a consistent way. I'm thankful that Google has decided to run public NTP servers with consistently smeared leap seconds.<p>Here are two Red Hat articles on how to deal with the leap second, from 2016 and 2015:<p><a href="https://access.redhat.com/articles/15145" rel="nofollow">https://access.redhat.com/articles/15145</a><p><a href="http://developers.redhat.com/blog/2015/06/01/five-different-ways-handle-leap-seconds-ntp/" rel="nofollow">http://developers.redhat.com/blog/2015/06/01/five-different-...</a>