I'm pretty sure OpenBSD core doesn't have any of those, and that's really what the project is caring about. Problems may happen in ports, but there's a reason why they're ports.
Also, as stated in the article:
> Finally, if you are one of the exceedingly few people for whom the clock being off by a second actually matters, then I'm pretty sure you also know how to deal with it.
I would think that waveform capture on the electric grid would be impacted when doing timeseries data logging and use in subsequent analysis. Frequently these will be relative time snapshots or using a different time basis so not sure if they are actually impacted.
The only time people would care that I'm aware of would be if the grid drooped at that exact time and one was trying to do analysis around that. Otherwise they are just doing things real time as they happen and time tracking is not necessarily involved except for logging.
Anyway I frequently run into timeseries trending clients that cannot handle displaying daylight saving time transitions correctly let alone hope that they handle leap seconds correctly.
Shouldn't `ntp`, over a short period of time, simply lengthen the actual amount of wall clock time per 'second' exposed to the kernel/userland? So there should never be a huge delta of 1s, nor should time ever go in reverse.
