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 --