ntpdate

Synchronize and set date and time

$ sudo ntpdate [host]

$ ntpdate -q [host]

$ sudo ntpdate -u [host]

$ sudo ntpdate -b [host]

ntpdate [-bBdqsvu] [-a keyid] [-e authdelay] [-k keyfile] [-p samples] [-P localport] [-t timeout] server [...]

-b
    Force a time step. Even if the offset is small, force a large time adjustment immediately rather than slewing.

-B
    Force a time slew. Even if the offset is large, force a gradual adjustment (slewing) over time. This option can cause the system clock to be temporarily incorrect.

-d
    Debug mode. Prints detailed debugging information to standard output, but does not modify the system clock.

-q
    Query only. Queries the NTP servers and prints the offset, but does not modify the system clock.

-s
    Log to syslog. Sends all output, including prompts and errors, to the syslog facility instead of standard output/error.

-u
    Unprivileged port. Sends outgoing NTP packets from an unprivileged port. Useful when firewalls block privileged ports.

-v
    Verbose output. Prints more detailed information about the time synchronization process.

-a keyid
    Authentication key. Specifies the key identifier to use for NTP authentication. Requires the -k option.

-e authdelay
    Authentication delay. Specifies the processing delay added to the roundtrip delay for authentication.

-k keyfile
    Key file. Specifies the path to the NTP authentication key file.

-p samples
    Number of samples. Specifies the number of samples to be acquired from each server. Defaults to 4.

-P localport
    Local port. Specifies the UDP port number for outgoing NTP packets. Defaults to an ephemeral port.

-t timeout
    Timeout. Specifies the maximum time to wait for a response from an NTP server. Defaults to 1 second.

server [...]
    NTP Server(s). One or more hostnames or IP addresses of NTP servers to query.

The ntpdate command is a legacy utility designed to set the local system's date and time by querying one or more Network Time Protocol (NTP) servers. Unlike continuous NTP daemons like ntpd or chronyd, ntpdate performs a one-shot synchronization. It queries the specified NTP servers, calculates the time offset between the local clock and the server's clock, and then adjusts the system time. If the offset is large, it will 'step' the clock (i.e., immediately jump the time). If the offset is small, it might 'slew' the clock (gradually adjust it). However, ntpdate is now largely deprecated.
Abrupt clock jumps can cause various issues, including corrupted log entries, transactional database problems, and issues with distributed applications. Modern best practice recommends using NTP daemons, which can smoothly adjust the clock and handle large offsets safely at boot (e.g., via ntpd -gq or chronyc -s), or in scenarios where a full daemon is not feasible, like some container environments for initial sync.

The ntpdate command is now largely considered deprecated. Modern Linux distributions and best practices recommend using a continuous NTP daemon like ntpd or chronyd. Abrupt time changes caused by ntpdate can lead to several issues, including:
log file inconsistencies (entries appearing out of chronological order),
data corruption in transactional systems (databases, distributed file systems) where time synchronization is critical, and
problems with applications sensitive to time jumps.
For initial synchronization at boot, it is strongly advised to use the `-gq` option with ntpd (e.g., `ntpd -gq`) or `chronyc -s` which are designed to handle large time offsets gracefully and then transition to continuous synchronization.

When ntpdate performs a 'step' adjustment (a large, immediate jump in time), it can disrupt various system processes and applications. This includes:
File system timestamps: Files created or modified during a backwards jump in time might appear to be from the future.
Log file integrity: Log entries might appear out of chronological order, making debugging difficult.
Transaction processing: Databases and other transactional systems rely on consistent time, and abrupt jumps can lead to data integrity issues or deadlocks.
Security mechanisms: Time-sensitive authentication protocols (e.g., Kerberos, some SSL/TLS certificates) can fail if the clock is abruptly reset.

For a one-time synchronization that handles large offsets gracefully, consider these alternatives:
ntpd: Use `ntpd -gq` to step the clock once if the offset is large enough, then exit. This is generally safer than ntpdate.
chronyc: Use `chronyc -s` to perform a one-shot synchronization. chronyc is known for its quick synchronization and robust behavior.

ntpdate originated as part of the official NTP reference implementation, serving as a simple client to synchronize the system clock with a remote NTP server in a non-continuous fashion. Its primary role was for initial clock setup, particularly on systems where the clock was significantly off or after a reboot. Over time, as NTP daemon implementations like ntpd matured, they gained the ability to handle large initial offsets gracefully (e.g., via the `-gq` option, which steps the clock if needed and then exits).
The development of chrony (with `chronyc -s`) also provided a more robust and faster alternative for one-shot synchronization. Due to the potential for negative system impact from abrupt clock changes, ntpdate's use has been actively discouraged by the NTP project and various Linux distributions, leading to its removal or deprecation in many modern OS versions.

ntpd(8), chronyd(8), hwclock(8), date(1)