It's constantly tested in the wild. Every time your computer does an NTP update and has to jump ahead one second or more, you've just tested it.
This is why the 2005 leap second crashed every Linux 2.4 kernel worldwide as I recall.
Thankfully there's been a push toward leap smear (certainly on every system I run) which should obviate this type of problem entirely.
Check out the "-x" flag in the manpage.
I recommend dumping ntpd and using chrony instead, and also configuring chrony for a time smear rather than the leap second as required by the standard.
The documentation also indicates it's rare for a 7x24 running server to suddenly step time (it only occurs when there's a 128 ms difference), unless you get serious network congestion that prevents sychroninization for an extended period, so a time step in a production server is uncommon. But a standard-compliant negative leap second requires time stepping, it's why I said there might be disruption.
I've dealt with datacenters getting a bad ntp config push, for example, or a bad firewall ruleset which blocks NTP. Fixing the config may inadvertantly step time.
There's a whole host of systems issues, sometimes involving VMs and sometimes bare metal which can cause this type of problem. The most simple of which is ntpd not running properly for a while, but this can also happen when systems get overloaded - extreme swapping and the like.
ntpd's behavior of non-monotonic time adjustments was brought to my attention after a developer uncovered database corruption, caused by a database which (correctly) assumed that time should be monotonically adjusted while the database server was running. I believe it mis-ordered a transaction log or something along those lines.
There are other, better ntpd implementations like chrony which can be configured to never step time. If time needs to be stepped, applications should be stopped and the machine should be removed from service first.
> There are other, better ntpd implementations like chrony which can be configured to never step time.
I totally agree that ntpd is worse, it has an aging code base with many potential security issues, chrony is a better and cleaner implementation. Nevertheless, I refuse to refer to "ntpd" as a worse implementation because it implemented the leap-second as the standard specified. Also, ntpd can be manually configured to never slew time (excluding leap second) if -x and -g are used.
> ntpd's behavior of non-monotonic time adjustments was brought to my attention after a developer uncovered database corruption.
BTW, my original topic here is how a negative leap second may cause service disruption, ntpd's behavior is only a footnote to that discussion. I think your experience only strengthened my original argument: if the standard leap second implementation (instead of smearing) is used, which is the case in a default configuration, something might happen. But I'm not sure, a negative leap second doesn't break the monotonic assumption. So it's all speculations...
PCs don't run anything crucial, usually you can set your clock to 2001 without visible problems, the same is not true for a server. A server uses ntpd, not a bruce-force ntpdate. Under ordinary conditions, ntpd adjusts the clock in small steps so that the timescale is effectively continuous and without discontinuities. But I think a negative leap second is quite violent.
> "oh, I'm more than one second behind now, I better start fuzzing and catch up".
No, ntpd would say, oh, leap second, now it's the time to tell kernel to delete a second! And if the kernel's negative leap second code path has a bug, kernel panics and everything crashes.
...Yes, you probably can force ntpd to ignore the leap second deletion and also force NTP to slew time only. This approach is similar to leap second smearing (which is considered a violation of standard but nevertheless an useful hack). But it requires manual configuration, by default the standard approach is used.
So the bottom-line is: Time will be forcefully stepped ahead by 1 second (which is an uncommon scenario on production server), and, it would not just be an ordinary step - it uses the operating systems normally untested negative leap second code path. I'm not sure what the consequences would be for various services, perhaps not much, but my worry is the interactions in a complex application can produce unexpected outcomes. Also, how many systems have implemented the negative leap second in the code path? And are they all tested?