Home / Alt manpages / systemd-timedated.service(8)

  • systemd-timedated.service(8)
  • Admin command
  • linux

Set Linux Time, Timezone and Network Sync Safely with timedatectl

You will finish with a checked way to inspect a Linux host's clock, set its timezone, and confirm whether network time synchronisation is active. The service behind these operations is systemd-timedated.service; its normal command-line client is timedatectl.

Allow about fifteen minutes. You need a shell and a systemd host. The examples were checked against systemd 255.4-1ubuntu8.17, whose installed manpage identifies the interface as systemd 255. Read-only checks need no elevated privileges. Changes to the clock, timezone, RTC mode or synchronisation service normally require authorisation, so the examples use sudo where appropriate.

1. Inspect the current state

Start with the human-readable status. This is safe to run on a production host and does not change the clock:

$ timedatectl status
               Local time: Sun 2026-09-27 08:00:59 BST
           Universal time: Sun 2026-09-27 07:00:59 UTC
                 RTC time: Sun 2026-09-27 07:00:59
                Time zone: Europe/London (BST, +0100)
       System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

The exact date, time, timezone and NTP provider will differ. The useful questions are whether the local clock has the expected offset, whether the system clock is synchronised, whether an NTP service is active, and whether the hardware clock is in local time.

For scripts, use machine-readable properties rather than parsing the aligned display:

$ timedatectl show
Timezone=Europe/London
LocalRTC=no
CanNTP=yes
NTP=yes
NTPSynchronized=yes

Properties can vary with the installed system and empty properties are hidden by default. Add --all when an absent value matters. Check the exit status immediately after a command if a script needs to distinguish success from failure.

Checkpoint

Record the current timezone and the RTC in local TZ value before making a change. That gives you a clear rollback target.

2. Understand the service boundary

systemd-timedated is normally activated on demand over D-Bus and exits when unused. Do not enable it as if it were a continuously running worker. Ask systemd to show the installed unit if you need to inspect its local hardening and activation configuration:

$ systemctl cat systemd-timedated.service
$ systemctl status systemd-timedated.service --no-pager

An inactive status after the query is not automatically a fault: the service may simply have finished after handling its request. The command that matters for normal administration is timedatectl, not a manual invocation of /usr/lib/systemd/systemd-timedated.

3. Select and set the timezone

List the exact timezone identifiers available on this host, then choose one from that list:

$ timedatectl list-timezones | grep -E '^(Europe/London|Europe/Dublin)$'
Europe/Dublin
Europe/London

Filtering is optional; the command prints one identifier per line. Do not use a display label such as UK time. The argument must be a timezone name such as Europe/London.

Changing the timezone changes the system's interpretation and display of local time, and alters the /etc/localtime symlink. This is a persistent configuration change. Confirm the target with the person responsible for the host before running it:

$ sudo timedatectl set-timezone Europe/London
$ timedatectl status | sed -n '/Time zone:/p'
                Time zone: Europe/London (BST, +0100)

If you selected the wrong zone, restore the recorded identifier:

$ sudo timedatectl set-timezone ORIGINAL/ZONE
$ timedatectl show --property=Timezone --value
ORIGINAL/ZONE

Replace ORIGINAL/ZONE with a real value from your earlier checkpoint. A timezone correction does not itself make an inaccurate system clock accurate.

4. Check the synchronisation provider

set-ntp controls the known network time synchronisation units. With the default configuration, enabling it starts the first existing service in the list; disabling it stops the known services. Inspect the result rather than assuming that the command selected systemd-timesyncd:

$ timedatectl show --property=NTP,NTPSynchronized,CanNTP
NTP=yes
NTPSynchronized=yes
CanNTP=yes
$ timedatectl timesync-status

timesync-status is specific to systemd-timesyncd. If another provider such as chrony is in use, this command may not describe the active provider. Use timedatectl status, the provider's own status command, and your package or service configuration to identify what actually owns time synchronisation.

Enabling or disabling NTP can start or stop a service and can change the system clock later. Treat it as a service-affecting operation:

$ sudo timedatectl set-ntp true
$ timedatectl status
$ timedatectl show-timesync --all

Output from show-timesync is machine-readable and can include the selected server, poll interval and last NTP message. It is empty or not useful when systemd-timesyncd is not the provider. Wait for a synchronisation update before declaring the host healthy.

To undo this specific change, disable network synchronisation only if the host's operating procedure permits the clock to run without it:

$ sudo timedatectl set-ntp false
$ timedatectl show --property=NTP --value
no

Do not use that as a general recovery step for a bad clock. Stopping time synchronisation can make logs, TLS validation and scheduled work less reliable. If a service was managed by a separate timekeeping tool, restore that tool's documented configuration instead.

5. Keep the RTC in UTC unless you have a reason not to

The RTC is the hardware clock used during boot. Linux normally keeps it in UTC and converts it using the system timezone. timedatectl status reports this as RTC in local TZ: no. That is the preferred arrangement for most Linux systems, especially hosts that may change timezone or observe daylight saving time.

set-local-rtc 1 switches the RTC to local time and also synchronises it from the system clock unless --adjust-system-clock is supplied. The local manpage warns that local RTC mode is not fully supported and can create problems during timezone and daylight-saving changes. Do not run this merely to make the RTC display match local wall-clock time. If dual-boot requirements force the setting, plan a maintenance window, record the existing value, and verify both operating systems afterwards:

$ timedatectl show --property=LocalRTC --value
no
$ sudo timedatectl set-local-rtc 0
$ timedatectl status | sed -n '/RTC in local TZ:/p'
          RTC in local TZ: no

The final command is an explicit restore to UTC mode. It can also update the RTC, so it is still a state-changing operation. Avoid changing RTC mode while another administrator or operating system is using the machine.

6. Set the clock only as a deliberate repair

set-time changes the system clock and updates the RTC. It can invalidate log ordering, scheduled jobs and time-based authentication, so prefer a working network time service. Use it only when you have confirmed that manual correction is required and have warned users of the operational impact:

$ sudo timedatectl set-time '2026-09-27 08:15:00'
$ timedatectl status

Replace the example with the verified time in the host's current timezone. Do not paste a guessed value into a production system. Once network synchronisation is available, enable it and verify System clock synchronized: yes rather than repeatedly correcting the clock by hand.

Done means

  • timedatectl status shows the intended timezone, clock state and RTC mode.
  • You used an exact identifier from list-timezones, not a display name.
  • You know which time synchronisation provider is active before using provider-specific commands.
  • Any timezone, NTP, RTC or clock change was authorised, verified and reversible from a recorded prior value.
  • You kept the RTC in UTC unless a documented dual-boot requirement justified local RTC mode.