Comment by globular-toast

This, I think.

Coming from someone whose daily work has been time sync for years (me):

If you look at Linux and many other Unix and Unix-like systems, to me it's the insertion of a leap second that has more potential for a failure than a removal.

Insertion ("positive leap seconds"): Time formatting functions will output "hh:mm:60" - this in itself is bound to catch some sofware off-guard - but internally during an insertion the same epoch value runs twice: 123456789.999999999 -> 123456789.000000000, which again is bound to cause some amount of confusion to assorted systems, and clearly the smear was implemented to combat this.

Surely this must be worse than the removal ("negative leap seconds"): 123456789.999999999 -> 123456790.000000000 - yes, still a discontinuity, but we have continuous increase and no ":60".

During my time spent developing time sync architectures and software, I tested both, ad nauseam, and tested it for others, a lot, GNSS simulators and all. Clearly precision time sync remains a specialised discipline, and pays my bills, so I don't mind, but I think this is a case of FUD combined with poor engineering practice and inadequate software testing eventually defeating a well-established timekeeping practice that (now this is more poetical than factual) allowed us to keep our timekeeping aligned with "nature".

I actually think we're in for a bigger mess when after this resolution we attempt to big-bang a batch update, but I will be retired and actually more likely dead and gone by the time this happens, so...