Set and Verify Linux's Local Timezone with /etc/localtime

/etc/localtime is a single symlink, and it is the whole reason a server can show the wrong hour to everyone who logs into it. You will finish with the system-wide timezone set to a named zone, plus a quick way to prove what applications will actually use. This guide uses systemd 255.4-1ubuntu8.17 as installed on the reference machine. Allow about ten minutes; you need sudo only if you are changing the host.

The setting affects how applications present local times. It does not set the clock, enable time synchronisation, or change an individual process that has its own TZ environment variable. Keep those as separate checks.

1. Inspect the current setting

Start with read-only commands; none of these need elevated privileges:

$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 33 ... /etc/localtime -> /usr/share/zoneinfo/Europe/London
$ readlink /etc/localtime
/usr/share/zoneinfo/Europe/London
$ timedatectl status

The link target is the useful part. The final path component, such as Europe/London, is the timezone identifier. Exact permissions, timestamp and status lines vary by machine. If /etc/localtime is absent, systemd's documented default is UTC, but applications may still carry their own timezone rules.

Checkpoint: write down the current identifier before changing anything. That gives you an immediate rollback value.

2. Choose a valid timezone identifier

Ask the installed timedatectl for the identifiers it knows about:

$ timedatectl list-timezones

Search that output rather than guessing a spelling or using a city name that is not in the zone database:

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

This guide uses Europe/London as an example; replace it with an exact identifier from your own list. A region such as Europe/London carries daylight-saving rules, while Etc/UTC is fixed. Do not confuse a display name such as BST with a zone identifier.

3. Change the system timezone

Changing the system setting requires elevated privileges and changes the host's persistent timezone configuration. It does not change the current instant, but services that display local time may show a different wall-clock value immediately. On a production machine, make the change during an appropriate maintenance window.

$ sudo timedatectl set-timezone Europe/London

A successful command normally prints nothing. It updates /etc/localtime through systemd's time-date service; you do not need to edit the symlink by hand. Manual replacement can lose the intended zone name, and /etc/localtime must not be a normal file or hard link under systemd's documented configuration model.

Checkpoint: verify both the tool's view and the link.

$ timedatectl show --property=Timezone --value
Europe/London
$ readlink /etc/localtime
/usr/share/zoneinfo/Europe/London

The first command reports the configured identifier, the second confirms the filesystem link. Both should agree. If either reports a different zone, stop before restarting services and work out which component is managing the host.

4. Confirm the displayed local time

Use timedatectl status for the host summary:

$ timedatectl status
               Local time: ... BST
           Universal time: ... UTC
                 RTC time: ... UTC
                Time zone: Europe/London (BST, +0100)

Dates and times in the output are intentionally variable. On a UTC zone, the local and universal clock display will normally share the same offset. On a region with daylight-saving rules, the abbreviation and offset depend on the date.

If you are checking a particular application, inspect it separately. A process started with TZ=Etc/UTC, for example, can deliberately ignore the host's local timezone for its own output:

$ TZ=Etc/UTC date
Thu Sep 24 21:05:25 UTC 2026
$ date
Thu Sep 24 22:05:25 BST 2026

The exact date and time will differ. The point of the comparison is that TZ is a per-process override; it is not evidence that /etc/localtime is wrong.

5. Recover from a wrong choice

Recovery: if the new setting is wrong, set the intended zone again using its exact identifier.

$ sudo timedatectl set-timezone Etc/UTC
$ timedatectl show --property=Timezone --value
Etc/UTC

This is the undo operation for the change made in this guide. If you recorded the old value in step 1, use that value instead of the example. Do not delete /etc/localtime as a first response: a missing link makes UTC the documented systemd default, which may hide the mistake rather than restore the intended regional zone.

If timedatectl set-timezone fails, inspect the error and check that the identifier appears in timedatectl list-timezones. A read-only image, container, unavailable systemd time-date service or insufficient privilege can all prevent the change. Do not force the operation by replacing files while those ownership and runtime questions are unresolved.

6. Keep clock and timezone checks separate

A correct timezone does not prove that the system clock is synchronised. In the status output, review System clock synchronized and NTP service independently. Conversely, a synchronised clock can still display the wrong local time if the timezone is wrong. Fix the relevant setting rather than changing both because one check failed.

Also remember that /etc/localtime is system-wide. Containers, language runtimes, application configuration and TZ can all choose another presentation. When an application disagrees with timedatectl, compare its environment and runtime configuration before changing the host.

Done means