Yes. Everyones been doing smearing (of slightly different flavors) since 2014ish when a kernel bug caused a bunch of havoc across linux and cisco boxes. It was a Bad Time.
For everyone that gets leap seconds right theres 10 who muck it up and have incorrect telemtry at best or data loss and crashes at worst. And this happens every time. So folks like GP who want or need to be Technically Correct are free to do so. But the smeared time from the big providers saves tons of hassle for regular developers and customers.
Disclaimer: principal at AWS, opinions are my own. I have no inside knowledge of this AWS NTP release.
The Bad Time was bad. But it was also bad when, a while later, at least one smearing server got into the public NTP pool, causing regrettable loss of time sync. (How do I know this? One of my servers caught the contagion and disagreed with my other servers by about a second. This can happen regardless of whether I’m trying to use smeared time myself.)
I find it quite regrettable that, 8 years later, large fleets and their unwitting customers use various, not necessarily compatible smears, and that they kludge it in via NTP. IMO a much better solution would be to make all this explicit:
Define UTCS as smeared UTC. Get everyone to agree at to exactly how it is smeared. Publish an RFC or similar. (Getting general purpose software to be aware of UTC vs UTCS is not necessarily required.)
Get all the major software vendors to implement UTCS by default, chrony-style.
Have the major cloud NTP servers continue to report UTC. Make the major NTP software implementations understand this all well enough so a server can run UTCS on its system clock but still report UTC to its own NTP clients.
If we're going to change time standards then we might as well just get rid of our current system of leap seconds altogether; I have never been able to find a good practical reason for them and the current UTC system doesn't even solve long-term time-keeping issues very well. All things considered it doesn't really strike me a problem that perception of time drifts by a few hours over a period of thousands of years, but if we really want to account for that then we can do it with a regular system – the slowing down of the earth's rotation is not completely regular in the short term, but it is in the long term.
But realistically, just don't use leap seconds and check again in a thousand years or so. Who even knows what the world will look like then.
You're basically describing TAI (International atomic time). UTC is just TAI with leap seconds applied, as I understand it mostly for political reasons (it was easier to get everyone to use atomic time if it's at most a 0.9 seconds off from the observational method used before).
We also have GPS time, which is TAI minus 19 seconds, which is probably the most "popular" monotonic time standard we have on the back of, well, GPS. Lots of choices!
Pretty much, yes, or a new standard which is regular that solves the unpredictability problem of leap seconds, as well as the "time actually doesn't work like almost everyone on the planet thinks it does"-problem.
Changing the time standard would be a huge international discussion involving many stakeholders, but that’s not at all what I’m suggesting.
I’m suggesting a new standard specifically for computers, not for commerce. The industry would agree on a smearing of time and anyone who wants to can use it at their discretion. And if the standard was at all sensible, it would say that one SHOULD NOT use it in any protocol intended to synchronize time between computers unless that protocol explicitly indicates whether the time is smeared.
The status quo is embarrassingly bad for interoperability. It’s a kludge implemented in a hurry to avoid a repeat of some bugs being triggered. The industry can and should do better.
For everyone that gets leap seconds right theres 10 who muck it up and have incorrect telemtry at best or data loss and crashes at worst. And this happens every time. So folks like GP who want or need to be Technically Correct are free to do so. But the smeared time from the big providers saves tons of hassle for regular developers and customers.
Disclaimer: principal at AWS, opinions are my own. I have no inside knowledge of this AWS NTP release.