https://news.ycombinator.com/item?id=28047714
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
By Google. Who started this whole trend of leap smearing in the first place.
VAX/VMS are way older than Google.
They were slow/maxed out for a while till we figured it out. The DBA rebooted a few but didn’t know why and it kept cropping up on others; I drilled into root cause with some google-fu.
Not mentioned in the article is that I think this issue occurred again in 2015. I don’t recall if it hit us because we hadn’t patched/upgraded some servers since 2012 (!) and had just relied on resetting the clock/rebooting, or there were more Linux bugs (see LWN below).
Good technical writeup from Linux weekly news: https://lwn.net/Articles/504744/
And more on Linux patching in 2015: https://lwn.net/Articles/648313/
IANA canonical list of leap seconds: https://data.iana.org/time-zones/tzdb-2018a/leap-seconds.lis...
Sorry, but no. This is so wrong I don't know where to start.
https://robotsinplainenglish.com/e/2022-11-20-stopwatch-time...
I can not see that. 23:59:58 - 23:59:59 - 23:59:60 - 00:00:00 is perfectly continuous, proper, and even monotonic, or at least as much as 23:59:58 - 23:59:59 - 00:00:00 is.
> When you receive a package with a computer-generated time stamp, it is showing this fudged UTC number, not the actual number of seconds according to the atomic stream.
I think you are mixing up UNIX timestamps (which are their own thing) and UTC. UTC and TAI both indicate exactly same thing, there is perfect 1:1 mapping between UTC timestamps and TAI timestamps (ignoring pre-1972 era).
