Contributed by pitrh on Sun Jun 28 20:17:50 2015 (GMT)
from the bounded leaps dept.
Christian Weisberger (naddy@)
let us all know
what we need to do to prepare for the impending leap second:
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.
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.
So, once more, the answer is: don't worry, OpenBSD does the right thing. Thanks to naddy@ for taking the time to let us know.