I can't think of many systems that would crater over a 61-second minute, then again, nothing I support these days considers time that critical. I have worked on systems where it would have mattered though. It was a really kick-ass fault tolerant unix box (Stratus) that processed and cut call detail records. Billing could easily have been impacted by something like that, but we had programmers who knew that, and actual test systems that we could test with.
This was back when Y2K was a thing, and we actually tested the Y2038 issue as well, when the unix 'time' counter rolls over. That had interesting results.
Speaking of which 2028 is coming.... glad I'll be retired by then.
The article mentions 23:59:60 implying the correction happens at the end of the day, but I imagine a correction would be less disturbing by sitting on 12:00:00 AM for the extra second given the disturbance can be washed over the following minutes. But the question, which time zone? Perhaps UTC -12:00
The article doesn’t correctly explain “32-bit” Unix issue. A 32-bit number can easily take us into the next millennium (0..4,294,967,295). The issue concerns the signed 32-bit number which we know is limited to the max value of 2147483647 (-2147483648..2147483647)
Good points regarding replication and minute granularity. Another reason why likely better to hold on the initial second of the hour at UTC -12:00.