Keeping system time correct

Setting it by hand, and why that is not enough

date prints the system time and, given a +FORMAT string, prints it however you like; date -s sets it. hwclock talks to the firmware clock, the battery-backed one on the board that keeps time while the machine is off: hwclock --systohc (or -w) copies system time into it and hwclock --hctosys (or -s) copies it back, which are the two directions worth remembering by name. Setting a clock by hand is always a correction, never a solution — quartz drifts, and a machine left alone will be seconds out within weeks and minutes out within a year.

hwclock writes to hardware, so it is an administrative tool and lives with the others: /sbin/hwclock, or /usr/sbin/hwclock on a merged system. A question that gives the full path is asking whether you know that an ordinary user cannot set the hardware clock. /etc/adjtime is where it records the drift it has measured, and whether the hardware clock is being kept in UTC or in local time.

The time ZONE is separate from the clock. /etc/localtime is the file the C library reads to convert the stored UTC into local time, and it is a copy of — or, on most distributions, a symlink to — one of the zone files under /usr/share/zoneinfo, so /etc/localtime pointing at /usr/share/zoneinfo/Europe/Berlin IS how the machine knows it is in Berlin. Debian family systems also keep the name in /etc/timezone. timedatectl set-timezone Europe/Berlin does the whole thing on a systemd machine, and timedatectl list-timezones prints the names it will accept.

$ timedatectl     Local time: Mon 2026-08-03 19:24:11 CEST  RTC time: Mon 2026-08-03 17:24:09 Time zone: Europe/Berlin (CEST, +0200)System clock synchronized: yes$ ls -l /etc/localtime... /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin$ /sbin/hwclock --systohc# system time written into the battery-backed clock

Synchronising

NTP arranges servers in strata: stratum 0 is a reference clock such as GPS or an atomic clock, stratum 1 is a server directly attached to one, and each level below is one hop further away. A client picks servers, measures round-trip delay, and steers its clock gradually rather than jumping — because a clock that jumps backwards breaks anything that assumes time only moves forward.

The classic daemon is ntpd, configured in /etc/ntp.conf with server or pool lines, and queried with ntpq -p, which prints the peers and which one is currently selected. chrony is the modern replacement, configured in /etc/chrony.conf and queried with chronyc sources; it copes far better with intermittent connections and virtual machines. ntpdate set the clock once at boot and is deprecated in favour of the daemons doing it properly.

Both configurations offer the same pair of directives, and the difference between them is asked directly. server binds ONE source. pool names something expected to resolve to several addresses and binds several of them as independent sources, which is what the public pool.ntp.org names are for — the numbered prefixes 0. through 3. exist so a host can list several pool lines and be handed different sets of servers. Per-source options are written after either directive: iburst sends a short rapid burst on the first exchange so a freshly booted machine synchronises in seconds rather than minutes, and maxsources caps how many sources are taken from a pool, so pool 2.pool.ntp.org iburst maxsources 4 yields at most four.

On a systemd machine, systemd-timesyncd is a lightweight SNTP client that does the common case, and timedatectl set-ntp true turns it on. timedatectl is also where you read whether the clock is synchronised at all.