Linux Timezone and NTP: timedatectl and chrony 2026

The timezone on a Linux server is set with timedatectl set-timezone, and accurate time comes from NTP synchronisation via systemd-timesyncd or chrony. Correct time is critical for logs, TLS certificates, cron jobs and databases. Here is the full setup.

Why time matters

A drifting clock breaks TLS certificate validation, scrambles the order of log entries and upsets cron and database replication. On a VPS the clock can drift, so NTP synchronisation is mandatory.

Step 1. The current state

timedatectl

The output shows local time, UTC, the timezone and the NTP sync status (System clock synchronized: yes/no).

Step 2. Setting the timezone

List the available zones:

timedatectl list-timezones | grep -i riga

Set the one you need:

timedatectl set-timezone Europe/Riga

Other examples: Europe/Moscow, Europe/Kyiv, UTC. Verify it:

date

Servers are often left on UTC — it makes distributed systems and log correlation simpler.

Step 3. Enabling NTP synchronisation

On most modern distributions the built-in systemd-timesyncd does the job:

timedatectl set-ntp true

Check the status:

timedatectl show-timesync --all
systemctl status systemd-timesyncd

The line System clock synchronized: yes means the time is being kept in sync automatically.

Changing the NTP servers for timesyncd

Edit /etc/systemd/timesyncd.conf:

[Time]
NTP=0.pool.ntp.org 1.pool.ntp.org
FallbackNTP=2.pool.ntp.org 3.pool.ntp.org

Restart the service:

systemctl restart systemd-timesyncd

The alternative: chrony (more accurate)

chrony holds accuracy better on unstable networks and on virtual machines. Installation:

apt install -y chrony
systemctl enable --now chrony

On Ubuntu the service is called chrony, on some systems chronyd. Check the time sources:

chronyc sources -v
chronyc tracking

chronyc tracking shows the offset and the accuracy of the synchronisation. Time servers are configured in /etc/chrony/chrony.conf:

pool 0.pool.ntp.org iburst
pool 1.pool.ntp.org iburst

iburst speeds up the first synchronisation.

Force an immediate correction:

chronyc makestep

The hardware clock (RTC)

Write the system time into the hardware clock:

hwclock --systohc

On a VPS the clock is usually virtual and synchronised by the hypervisor, but the command is still useful as a check.

systemd-timesyncd or chrony

For a single VPS timesyncd is enough. If the server serves time to the network or you need maximum accuracy, use chrony.

Troubleshooting synchronisation

If timedatectl reports System clock synchronized: no, work through these steps.

Check whether the NTP servers are reachable (they use UDP port 123):

timedatectl timesync-status

Make sure the firewall does not block outgoing UDP 123:

ufw status | grep 123

Outgoing connections usually need no rule, but if your policy is deny outgoing, add one:

ufw allow out 123/udp

Look at the time service journal:

journalctl -u systemd-timesyncd -n 30

Checking the offset manually

Compare the server clock against a public source. Install ntpdate for a one-off check:

apt install -y ntpdate
ntpdate -q pool.ntp.org

The -q flag only queries and reports the offset without changing the clock. An offset close to zero means the time is accurate.

Locale and date format

Timezone and locale are two different things. Check the locale:

localectl status

Set it, for example, to get the date format you expect:

localectl set-locale LANG=en_US.UTF-8

This affects the output of date and the logs, but not the system time itself.

Automation across several servers

If you run many servers, define a single NTP pool through a configuration management system (Ansible, cloud-init). Every node then syncs against the same sources and log timestamps stay comparable between machines — which is critical when you investigate a distributed incident.

Frequently asked questions

Can timesyncd and chrony run together? No, they conflict. When you install chrony, disable timesyncd: systemctl disable --now systemd-timesyncd.

Why does the time drift after a reboot? Because NTP is not enabled. Run timedatectl set-ntp true or install chrony.

Should I use a local timezone or UTC? UTC is more convenient for servers. Use a local zone only if applications or reporting require it.

How do I check the synchronisation accuracy? chronyc tracking shows the offset in seconds. Millisecond values are normal.

Does time affect TLS? Yes. With a large clock offset certificates are treated as invalid and HTTPS breaks.

A stable server starts with the basics. Deploy your project on a VPS plan or a VPS for security and VPN. Full maintenance can be taken over by Server administration.