timedatectl Command: Tutorial & Examples

The one command for your server's time, timezone, and clock sync — and the first place to look when timestamps look wrong.

What It Is

timedatectl shows and controls everything about a Linux server's sense of time: the current clock, the timezone, whether the clock is being kept accurate over the network, and how the hardware clock is interpreted. It's part of systemd, so it's on essentially every modern distribution, and it replaced the old scatter of date, hwclock, and hand-edited /etc/localtime symlinks with one coherent tool. When logs are timestamped an hour off, a certificate "isn't valid yet," or a cron job fires at the wrong moment, timedatectl is where you start.

Reading is safe and instant; setting requires root and changes real system state, so we'll be clear about which is which. Time feels like a detail until it isn't — and on a server, a wrong clock quietly breaks TLS, authentication (Kerberos tickets, TOTP), distributed databases, and every log correlation you'll ever try to do. This page makes the whole thing legible.

Your First Look

Run it with no arguments for the complete picture:

timedatectl

               Local time: Wed 2026-06-03 19:19:10 CEST
           Universal time: Wed 2026-06-03 17:19:10 UTC
                 RTC time: Wed 2026-06-03 17:19:10
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Seven lines, and together they answer every time question you can have about the box. Local time is the wall-clock in your timezone; Universal time is the same instant in UTC (the absolute reference every server should think in); RTC time is the hardware "real-time clock" on the motherboard that keeps ticking when the machine is off. The bottom three lines are the ones that actually catch problems — and the most important is System clock synchronized: yes.

How I Read It

My eyes go to two lines first, in order.

First: System clock synchronized and NTP service. If sync is yes and the NTP service is active, the clock is being continuously corrected against internet time servers and I can trust it to within milliseconds — case closed. If sync says no, the clock is free-running on the motherboard crystal, which drifts seconds per day, and that drift is the root cause of a huge share of "weird time" bugs — expired-too-early certs, failed logins, confusing log ordering. A no here is the single most useful thing this command tells you.

Second: Time zone. This is where logs being "an hour off" usually comes from — the clock is correct in UTC but the box is set to the wrong region, so local timestamps are shifted. The fix is a timezone change, not touching the actual time. Keeping these two ideas separate — is the underlying instant correct (NTP) versus how are we displaying it (timezone) — is the whole skill, and it's what stops people from "fixing" a timezone display bug by wrongly shoving the clock an hour, which then breaks everything that runs in UTC.

The Fields, Explained

Local time — the current time in the configured timezone, the way humans on this box see it.
Universal time — the same moment in UTC, the timezone-independent truth. Servers and logs should reason in UTC; local time is just a display.
RTC time — the hardware clock on the motherboard, battery-backed so it survives power-off. At boot the system clock is seeded from it; while running, NTP keeps the system clock right and periodically writes back to the RTC.
Time zone — the region (Europe/Berlin), its current abbreviation (CEST), and offset from UTC (+0200). The offset shifts automatically across daylight-saving changes because the zone name encodes the rules.
System clock synchronized — yes if a time-sync service has disciplined the clock. The trust signal.
NTP service — active if systemd-timesyncd (or another NTP/chrony daemon) is running and keeping time.
RTC in local TZ — should be no. Keeping the hardware clock in UTC avoids a notorious class of dual-boot-with-Windows time bugs.

Reading It by Example

synchronized: yes, NTP service: active. Healthy. The clock is disciplined to internet time; you can stop suspecting time entirely and look elsewhere for your bug.

synchronized: no, NTP service: inactive. Nobody is correcting the clock — it's drifting. This is your culprit for TLS "not valid before/after" errors, failed Kerberos/2FA auth, and out-of-order logs across machines. Turn sync on: timedatectl set-ntp true.

Local time right, but logs look an hour off. The instant is correct (check Universal time matches reality) but the Time zone is wrong for where you expect. Fix the zone, leave the clock: timedatectl set-timezone Europe/Berlin.

RTC in local TZ: yes on a dual-boot box. The hardware clock is being read as local time, so every reboot between Linux and Windows can jump the clock by your UTC offset. Set it to UTC: timedatectl set-local-rtc 0.

Two servers disagree by a few seconds and a distributed DB is throwing errors. Both probably have synchronized: no. Clusters (databases, Kerberos, TLS) assume tightly-synced clocks — enable NTP on every node.

Cheat Sheet

Reading (no privileges needed):

timedatectl — the full status (the screen above)
timedatectl list-timezones — every valid zone name (pipe to grep: timedatectl list-timezones | grep Berlin)
timedatectl show — the same data as machine-readable key=value for scripts

Setting (needs root):

timedatectl set-ntp true — turn on network time sync (the usual fix)
timedatectl set-timezone Europe/Berlin — change the timezone (display only; doesn't move the instant)
timedatectl set-time '2026-06-03 19:20:00' — set the clock by hand (only when NTP isn't an option; disables NTP)
timedatectl set-local-rtc 0 — keep the hardware clock in UTC (recommended)

How You'll Actually Use It

Ninety percent of the time you type timedatectl, read the synchronized/NTP lines, and either relax or run timedatectl set-ntp true. The other common job is fixing a freshly-installed server's timezone with set-timezone so its logs read in the region you operate in. You almost never set-time by hand — letting NTP discipline the clock is both easier and far more accurate, and manual setting actively turns sync off. For watching the actual ticking clock or formatting timestamps, date is the partner tool; timedatectl is for configuration and health, date is for reading and formatting.

Gotchas

set-time disables NTP. You can't hand-set the clock and keep network sync — they conflict, so a manual set turns sync off. On anything with internet access, prefer set-ntp true and never touch set-time.
Timezone ≠ clock. set-timezone changes only how time is displayed; the underlying UTC instant doesn't move. Don't "fix" a timezone problem by changing the time — you'll break everything that works in UTC.
synchronized: yes can lag reality. It means the clock was disciplined; if the network or NTP server later dies, it can still read yes while slowly drifting. For critical systems, monitor the actual offset, not just this flag.
set-ntp true needs a sync daemon present. It enables systemd-timesyncd (or your installed chrony/ntpd). On a minimal image with none installed, install one first.
Containers share the host clock. Inside most containers you can't set time — the kernel clock belongs to the host. Fix time on the host, not in the container.

History & Philosophy

timedatectl arrived with systemd to replace a genuinely confusing pile of half-overlapping tools — date for the clock, hwclock for the RTC, manual /etc/localtime symlink surgery for the zone, and a separate ntpd config for sync. Folding them into one status-and-control command, with a single clear screen, was a real usability win: now one line answers "is this server's time trustworthy?"

The idea worth carrying away is that a server should think in UTC and merely display in local time. UTC is the one clock with no daylight-saving jumps and no regional ambiguity, so every log, database timestamp, and cross-machine comparison is sane when the underlying instant is UTC and the timezone is just a presentation layer on top. Get that mental model right — instant in UTC, zone for humans, NTP keeping it honest — and an entire category of maddening, intermittent "time" bugs simply stops happening to you.