hi there,
i have always used the EXAMPLE given in rdate(8) for manually
syncing the clock on my vmware openbsd images after coming back
from hybernation. but i have noticed that even after ntpd
stabilized the situation, the clock was still always off:
$ sudo rdate -ncv ptbtime1.ptb.de
Sun Jul 24 14:13:35 CEST 2011
rdate: adjust local clock by 23.997476 seconds
after more head scratching i realised that the man page
is using -c for correcting leap seconds.
$ sudo rdate -nv ptbtime1.ptb.de
Sun Jul 24 14:27:38 CEST 2011
rdate: adjust local clock by -24.000235 seconds
ntpd doesn't seem to care/know about leap seconds and nor do i.
from rdate(8):
-c Correct leap seconds. Sometimes required when synchronizing to
an NTP server. When synchronizing using the RFC 868 protocol,
use this option only if the server does not correctly account for
leap seconds. You can determine if you need this parameter if
you sync against an NTP server (with this parameter) or
(recommended) check with a local radio controlled watch or phone
service.
"sometimes required" is quite ambigous. when? the "You can ..." sentence
is not making a lot of sense to me i am afraid. it also does not make it
clear that the -c corrected time will be a different "breed" of time,
a breed most of the internet does not seem to care about, making the
openbsd box always 24s off from the rest of the world until ntpd adjusts
it gradually back..
i believe a better example would be:
- # rdate -ncv ptbtime1.ptb.de
+ # rdate -nv ptbtime1.ptb.de
i also think that suggesting using rdate in cron is outright
dangerous and a big no-no _especially_ with ntpd in base.
for example older versions of dovecot used to simply die
if time jumped backwards (http://wiki.dovecot.org/TimeMovedBackwards).
-f
--
