[joerichey]

For future leap seconds, Google (including GCP) are planning to use a "standard" smear (https://developers.google.com/time/smear). This is also the same smear used by AWS.

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.

[ncmncm]

They will be wrong all day long, not just for one second. AWS will be, too, evidently.

Few others will do anything so idiotic.

[guipsp]

They will be wrong by at most one second. And being wrong doesn't even matter, as long as everyone (or rather, all your servers) agree.

[fanf2]

At most half a second, in the middle of the smear at midnight when the leap second is applied.

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. ]

[lifeisstillgood]

They are "wrong" technically but they won't be "wrong" more than a packet getting routed transatlantic would be - so if I send two packets from my laptop in London - one to AWS in London during the smear and one to another laptop in NYC, and timestamped the packets arrivals, the time stamps would likely be similar. Yes "wrong" but if it's a problem then it's a problem you have with speed of light. The answer is to find a different / reliable method of ordering.

[staticassertion]

What are the practical issues with potentially being wrong for one day by at most one second?

[a9h74j]

I assume finance and control systems to start. I might be helpful to have a fallback time-ordering algorithm not dependent upon one monotonic clock, but then you might have a rarely-used fallback to have bugs in, I imagine.

[Too]

What are the practical issues for finance and control systems?

[denton-scratch]

For finance, it matters what order events occur in. I've never messed with control systems, but I suppose similar issues arise.

[Too]

Control systems, or any form of embedded safety critical system, use monotonic clocks where calendar time is a complete non-issue.

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?

[GoblinSlayer]

Ordering can be solved by a mutex.