Quoting Adam Borowski (kilobyte@???):

> Please don't do this, for reasons already mentioned.
>
> If your hwclock is so broken ntp refuses to adjust the clock, you may run
> ntpdate (or rdate -n) at boot, but then you should start ntpd (or chrony)
> normally.

Please don't run ntpdate.

ntpdate is deprecated upstream (ISC) and will soon get dropped entirely.
It would be an excellent idea to get used to this. Quoting the manpage:

Disclaimer: The functionality of this program is now available in
the ntpd program. See the -q command line option in the ntpd - Network
Time Protocol (NTP) daemon page. After a suitable period of mourning,
the ntpdate program is to be retired from this distribution.

http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate has more details.


> I haven't read the man pages in a while (which you should do before doing
> anything), but I recall that ntpd refuses to adjust time when the clock is
> wrong on the order of hours.

The default window is not hours but rather 1000 seconds. _But_ there is
an override, the '-g' switch to ntpd. Thus: 'ntpd -q -g' Quoting the
manpage:

       -g     Normally, ntpd exits with a message to the system log if the
              offset exceeds the panic threshold, which is 1000 s by default.
              This option allows the time to be set to any value without
              restriction; however, this can happen only once.  If the 
              threshold is exceeded after that, ntpd will exit with a message
              to the system log.  This option can be used with the -q and -x
              options.

       -q     Exit the ntpd just after the first time the clock is set.  This
              behavior mimics that of the ntpdate program, which is to be
              retired.  The -g and -x options can be used with this option.
              Note:  The kernel time discipline is disabled with this option.

There's also a brain-dead variant protocol called 'SNTP' (Simple Network
Time Protocol) beloved of Microsoft (i.e., MS-Windows has no NTP
capability as provided, only SNTP, which got added starting with Windows
2000), and of course the systemd developers _love_ it and are pushing it
heavily, because (it appears) they're idiot MS-Windows users and don't
understand technology.[1] ISC's NTP Project reference implementation's
developers are, with what I hope is reluctance and a sense of
resignation, in the middle of developing a 'sntpd' piece, but I wouldn't
touch it on a dare.

Honestly, I'm considering OpenBSD Project's competing OpentNTPd
implementation _instead_ of ISC's, to reduce security exposure and opt
for less-complex code. The only significant[2] tradeoff is that it
lacks (and doesn't aspire to) microsecond precision, considering
simplicity and security more important -- and I think that for most
use-cases that is the correct balance.

https://en.wikipedia.org/wiki/OpenNTPD

[1] https://wiki.archlinux.org/index.php/systemd-timesyncd
[2] http://www.advogato.org/person/dtucker/diary/52.html