There's good reason it's in the standard. Many applications of computer science rely on being able to accurately measure time.
Having every second increased by a non-trivial amount (~0.001%) on some days, and not on others, will produce subtly wrong results in all kinds of fields, from manufacturing to astronomy.
"We recommend that you don’t configure Google Public NTP together with non-leap-smearing NTP servers."
If you point your NTP clients to time1.google.com to time4.google.com then don't point them to anything else.
That's all.
If you use Google's time servers you are using them either to be fully in sync with Google or because you like the time-smearing feature. In both cases, just use them, don't mix. Think it as a non-standard-service which is for convenience API compatible with the "standard" NTP.
As magicalist pointed, there are already other smearing algorithms online:
and Google plans to switch to the new algorithm soon. If all those who need smear standardize around one algorithm, it's going to be even better: there will be one more standard, with the new name, but then it will be even more obvious to everybody what's going on. Obviously both approaches are needed, depending on the usage scenario.
Wow, that's a really boneheaded thing to put in a standard. I think we can all agree that it's important to make leap smearing available for those who want to use it, especially considering the bugs in leap second handling for common NTP clients.
I disagree. The point of NTP, and of time services in general, is that everyone agrees about the time. If an organisation wants to use non-standard time it can, but public-facing NTP servers should all agree and all provide the standard time. Google, for whatever reasons, is making its NTP servers deliberately wrong, and there is no mechanism in NTP for a server to say "I'm using time-smearing". So they shouldn't be doing this on public-facing NTP.
Then NTP has already failed. Most systems are already incapable of agreeing on whether it is 23:59:59 or 23:59:60 on days with leap seconds. There is simply not an API that will let you distinguish the two.
It is better to be deliberately wrong in a controlled fashion than to be accidentally wrong because you never expected your clock to be non-monotonic. You seem to be arguing for the status quo, are you aware of just how deeply broken the status quo is?
Unix, for example. That's a pretty big example. Look at gettimeofday. Completely incapable of handling leap seconds in any reasonable way, except if you use smoothing.
Windows, for example. That's another pretty big example. Just ignores the leap second bit and goes backwards at the next synchronization.
I'm not even talking about bugs here—these are straight up design flaws.
There are actually two reasonable ways of handling leap seconds with gettimeofday(). The first, which is in actual use by a range of people, is to define that the kernel time is actually a TAI-10 count not a UTC count. Arthur David Olson's "right" timezone system does this. The second is to allow the microseconds count to go up to 2,000,000.
I wonder how many clients handle that correctly. How many log files will have timestamps at "23:59:59.1500" instead of "23:59:60.500"? If you are going to break APIs you might as well make a new one instead.
And if you replace a simple API with one that requires distributing leap-second tables…
Network Time Protocol Best Current Practices
draft-ietf-ntp-bcp-02
1. Introduction
NTP Version 4 (NTPv4) has been widely used since its publication as
RFC 5905 [RFC5905]. This documentation is a collection of Best
Practices from across the NTP community.
Don't think it is a standard, looks like work in progress.
Imho a bit short notice to publish something like that Nov. 30th. Just at the time when they had to start advertising the leap second in NTP (or not advertise it where smearing). Not sure but somehow it sounds in draft-ietf-ntp-bcp-02 that that clients may need attention.
Clients that are connected to leap smearing servers must not apply
the "standard" NTP leap second handling. So if they are using ntpd,
these clients must not have a leap second file loaded, and the
smearing servers must not advertise that a leap second is pending.
