(One of) the biggest pains with leap seconds is they are so infrequent and so I/O-bound, that they are almost impossible to test. What is less functional than r

(One of) the biggest pains with leap seconds is they are so infrequent and so I/O-bound, that they are almost impossible to test. What is less functional than relying on a random change in a radio signal below the noise floor coming through dedicated hardware, which is finicky and doesn't work well indoors (E-coated glass windows? Fuggetaboutit). I think one thing that could have be easily done to help is emit leap-sub-seconds (100-500ms) more frequently, so we would have more chances to detect bugs per year. Alas, leap seconds are baked in as int8 so that's never gonna happen. That's also totally not the mindset when these systems were designed, which is kind of my point. The right kind of forethought could have avoid much of this pain. Option 1: We have 2 time standards out of sync. Let's make an announcement yearly-ish and add 1 second of offset that everything has to obey. Option 2: We have 2 time standards out of sync. Let's continuously track the offset to (whatever precision) and this offset is just always part of the correction (like we do time zones), rather than this value which you just assume is static 99% of the time.