It's not always the right approach, but it's a good reminder to consider "do nothing" as the proper response to a weird edge case that is presented as a [potential] problem.
<a href="http://cr.yp.to/proto/utctai.html" rel="nofollow">http://cr.yp.to/proto/utctai.html</a><p><a href="http://cr.yp.to/proto/taiclock.txt" rel="nofollow">http://cr.yp.to/proto/taiclock.txt</a><p>I am just a dumb user.
I use clockspeed (sntpclock, clockadd and clockview) with a short list of compatible servers I consider "reliable". As far as I can tell, it works.<p><a href="http://cr.yp.to/time.html" rel="nofollow">http://cr.yp.to/time.html</a>
I'm not very familiar with ntpd, but this article doesn't cover what would happen if the half hour polling just happens to poll right during the leap second. If the code receives "59 minutes and 60 seconds" but doesn't expect that to be possible, I could imagine that being a problem.
For anyone curious about this:<p><pre><code> 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.
</code></pre>
One alternative to NTP is PTP.[1] Quoting:<p><pre><code> IEEE 1588 is designed to fill a niche not well
served by either of the two dominant protocols,
NTP and GPS. IEEE 1588 is designed for local
systems requiring accuracies beyond those
attainable using NTP.
</code></pre>
[1] <a href="https://en.wikipedia.org/wiki/Precision_Time_Protocol" rel="nofollow">https://en.wikipedia.org/wiki/Precision_Time_Protocol</a>
Out of curiosity...<p>What it the NTP server is running openBSD? =P<p>(not sure if this question makes sense... Anyway, it seems some OS has to worry about leap seconds...)
It's not a bug, it's a feature we chose not to implement.<p>Weird that a security-centric OS would be cavalier with time when some cryptosystems are time-sensitive.