Fred Gleason wrote:
I suspect that one of the primary reasons that such time resets have been so fraught [...] is their relative rarity [...] deployed systems rarely have to cope with one and thus get the inevitable bugs identified and shaken out.
It would almost be beneficial if such an event would occur at least once per annum, to allow the 'reset' logic to be regularly exercised.
A few years back I did a bunch of work (sadly as yet unpublished) trying to improve support for leap seconds, and one of the things I wrote was a mock NTP server serving time on hundreds of different test ports, with each port offering fake leap seconds on a different day. So, theoretically, if you wanted to test your system's leapsecond handling, all you'd have to do was pick the right port and you could have your leap second tomorrow. (Unfortunately it wouldn't have been nearly as convenient to use as I had anticipated, because it turns out that stock ntpd doesn't offer an easy way to configure an upstream server connection on other than the default port 123.)