Yes. Leap seconds are just a thoroughly bad idea, from any angle.
Yet, not nearly so bad as Google's approach: no leap, but a 24-hour smear, during which 24 hours they are out of sync with literally everybody else in the world.
Yet, not nearly so bad as Google's approach: no leap, but a 24-hour smear, during which 24 hours they are out of sync with literally everybody else in the world.
It seems like if the ITU decides to keep the leap second (a bad idea, in my opinion), the large infrastructure providers will just use the same standard smear for their clocks.
Few others will do anything so idiotic.
The Facebook smear is asymmetrical so it starts off 1 second off just after the leap second, and subsequently corrects itself.
[ The reason Google and Amazon use a linear smear is because NTP clients try to measure the rate difference between their local clock and the reference clocks; if that is different every time the NTP client queries its servers, it will have trouble locking on and accurately matching the smear curve. You can mitigate this somewhat by fixing a higher NTP query frequency, but that’s a heavy-handed fix for an engineering mistake. ]
Ordering of events, on what scale are we talking here? If it’s just within a transactional database there are multitude of ways to do it. Even distributed dbs have such features without relying on perfect time. If you are looking at a spanner style db you need a lot more guarantees than “I just used the time my cloud provider assigned to my vm”, plus being in sync only matters within your own cluster?
I think smearing can help reduce outages. The article mentions that reddit and Cloudlare had outages caused by leap seconds when they weren't smearing. I think it's a tradeoff between being standard and avoiding outages.
Disclosure, I work at Google.
> The AWS Management Console and backend systems will NOT implement the leap second. Instead, we will spread the one extra second over a 24-hour period surrounding the leap second by making each second slightly longer.
https://aws.amazon.com/blogs/aws/look-before-you-leap-the-co...
AWS and Google would like to think the internet is just them, but they are a tiny little bit of it.
Systems that use atomic clocks might have been able to do 10,000 transactions per second will suddenly only be able to do 2 transactions per second if they contain a node that doesn't use the same smearing.
Yes I could come up with an algorithm where this is a problem, but in most cases I’d favor a solution that doesn’t depend on separate systems having clocks perfectly in sync.
If you don’t, then you already have to deal with standard drift with ntp anyways so Googles time smear is the least of your problems
https://dl.acm.org/doi/10.1145/112600.112601
Google spanner uses stuff like this with a clock called TrueTime. I don’t know how leap seconds / smearing is handled in that system.
From a purely academic perspective, it means from noon preceding a leap second to noon after the leap second there's a difference between UTC and what google (and anyone else who does smears) reports as the time. If you really hated yourself and were trying to use timestamps from conflicting sources to order transactions in a database, for example, this could mess up the order of your transactions which could have all sorts of fun consequences.
Eliminate UTC leap seconds, and the overwhelmingly worse smear problem vanishes too.