As you may have heard, a leap second will be upon us at 23:59:60 UTC on June 30.
The sky will fall, civilization will end, and dinosaurs will roam the earth again. Well, maybe not. Neither the OpenBSD kernel nor OpenNTPD handle leap seconds in any way. So what will happen? After the leap second, your OpenBSD system's time will be off by, well, one second. Gasp, shock. Let's say you synchronize your clock with ntpd against a server that does have the correct time. At the next poll, i.e. within about half an hour, ntpd will notice the offset and correct it, which will take a few minutes. That's it. (I expect ntpd will drop down to a short poll interval and the frequency correction will fishtail a bit since it's a differentiator reacting to a jump.) Unless you obsessively watch your ntpd, you won't notice a thing. All the terrible things you may read that might happen, or that did happen to Linux in the past, are side effects of systems that do attempt to handle leap seconds, so that they always have the correct time at the price of a confusing extra second popping into existence. 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. PS: Any hate mail about leap seconds should be directed to (1) the people who insist that Earth's celestial wobbling around must have primacy for time keeping and (2) the people at POSIX who specified that time_t must not include leap seconds, which means we can't just let the time zone database handle this. -- Christian "naddy" Weisgerber na...@mips.inka.de
