Logs in one time, cron in another, a certificate "not yet valid". timedatectl on a live server: zone, synchronization and a one-minute clock check.
The nightly backup runs at some odd hour, events in the log come out of order, and apt suddenly claims a repository is "not valid yet". Most of the time it's the same boring thing: the server's time zone isn't the one you think it is, or the clock has wandered off. Let's look at how to spot that and fix it with timedatectl.
In short.
timedatectlwith no arguments prints local time, UTC, the time zone and, most importantly,System clock synchronized: yes.sudo timedatectl set-timezone Europe/Berlinchanges the zone andtimedatectl list-timezoneslists valid names. A server that serves people in several countries is easier to run on UTC. Accuracy comes from a synchronization service, on Ubuntu that issystemd-timesyncd, andtimedatectl timesync-statuschecks it.
What timedatectl shows
It's the stock systemd tool for anything time-related: it reads and changes the zone and turns synchronization on and off. Nothing to install. Run it with no arguments (reading needs no administrator rights):
timedatectl
This is the real output from an Ubuntu 24.04 server:
Line by line:
- Local time is the time in the server's zone.
date, the cron schedule and most programs follow it. - Universal time is the same instant in UTC, world time with no seasonal shifts. The gap to local time is the zone offset, three hours here (
+0300). - RTC time is the hardware clock (emulated on a virtual machine).
RTC in local TZ: nomeans it stores UTC, which is the right choice for Linux. - System clock synchronized: yes means the clock has been checked against time servers. If it says
no, fix synchronization before anything else. - NTP service: active means the service that does the checking is running.
How to check the time zone of a server
It is on the Time zone line above. If a script needs only that value, ask for it directly:
timedatectl show -p Timezone --valueBehind the name there is an ordinary link. On Ubuntu and Debian the zone is set by /etc/localtime, which points to an entry in the time zone database:
ls -l /etc/localtime && cat /etc/timezoneOn our server it looks like this:
The link and /etc/timezone normally agree. If yours differ, trust the link, because most programs read it.
How to change the time zone
First find the exact name. Zones are named "Continent/City", not "EST" or "GMT+3": that way the database remembers both the offset and the dates of daylight saving changes. Filter the list by region:
timedatectl list-timezones | grep Europe/The list holds hundreds of lines and you need two or three of them, such as Europe/Berlin, Europe/Helsinki or Europe/Amsterdam. Once you have the name, change the zone (this command needs administrator rights):
sudo timedatectl set-timezone Europe/BerlinAn ordinary user without sudo gets a refusal: Failed to set time zone: Interactive authentication required. That is a permissions problem, not a wrong name. After the change, run timedatectl again and restart cron so that scheduled jobs follow the new time: sudo systemctl restart cron.
UTC or local time
My rule of thumb: if one team in one country uses the server, set that country's zone and you never do time arithmetic in your head. If the logs are read from different places, the server serves customers in several countries, or you plan to gather logs from several machines in one place, keep UTC. UTC's big plus is that it never shifts: in autumn an hour does not happen twice, in spring it does not vanish, and a scheduled job does not run twice or not at all.
You can look at the time in any zone without changing the system one, with a single environment variable:
TZ=America/New_York date; TZ=UTC dateThe TZ variable affects only that one command. It is handy when you want to know what time it is for a colleague without touching server settings.
The clock must not drift: time synchronization
A correct zone won't save you if the clock itself is wrong. And a VM's clock does slip: the host gets busy, a process stalls, someone restores a disk snapshot. So the server runs a small service that every half hour or so compares its time with reference servers over NTP (Network Time Protocol). Ask it how it's doing:
timedatectl timesync-statusThree lines matter more than the rest:
- Server is who the machine checks against. On Ubuntu the default is
ntp.ubuntu.com. - Offset is how far the clock was from the server at the last check.
-639usis minus 0.6 milliseconds, ideal for any website server. Worry when it approaches seconds. - Poll interval is how often the check happens. 34 minutes is the ceiling: the service concluded that the clock behaves steadily and stopped asking without need.
If synchronization is off, switch it on and look at timedatectl again:
sudo timedatectl set-ntp trueOn Ubuntu the work is done by systemd-timesyncd, a light service that ships with systemd. For a website, a bot or an ordinary server its accuracy is more than enough. The separate chrony package is for cases where fractions of a millisecond count or the server hands out time to other machines. You do not keep both: installing chrony usually removes the systemd-timesyncd package on its own.
What breaks when the time is wrong
A bad clock rarely announces itself. It shows up as something else, and people go digging in the wrong place for an hour:
What you see | What it really is | What to do |
|---|---|---|
| The clock is behind the repository | Check |
A browser or | The certificate is checked against the server clock | Check the time first, and only then the certificate itself |
Two-factor (TOTP) codes are rejected | A code lives 30 seconds, and a larger offset breaks it | Look at |
A backup runs "at the wrong time" | The server zone is not the one in your head | Read |
Log entries from different servers come out in the wrong order | The machines have different zones or clocks | Move everything to UTC and enable NTP everywhere |
A one-minute check
There is a simple way to confirm the clock without trusting the service itself: compare the server time with the Date header that any HTTPS site returns. Request only the headers and compare with date -u:
date -u; curl -sI https://www.ubuntu.com | grep -i "^date"A second or two of difference is fine, because the two commands don't run at the same moment. If the gap is minutes or hours, look for the cause: switched-off synchronization, UDP port 123 blocked in a firewall (NTP uses UDP), or a wrong zone that you mistook for drift. The service journal gives details, as we showed in the journalctl article: sudo journalctl -u systemd-timesyncd is enough.
FAQ
How do I check the time zone of a Linux server?
Run timedatectl and read the Time zone line. The short form timedatectl show -p Timezone --value prints only the name, for example Europe/Berlin.
How do I change the time zone in Ubuntu?
Find the name with timedatectl list-timezones | grep City and run sudo timedatectl set-timezone Continent/City. Then check the result with timedatectl again.
Should a server use UTC or local time?
One team in one country can use local time. If the service reaches several countries or you collect logs from several servers, use UTC: it has no daylight saving shift and no confusion when reading journals.
Why does timedatectl say "System clock synchronized: no"?
The synchronization service is off, cannot reach the time servers, or has only just started and has not checked the clock yet. Enable it with sudo timedatectl set-ntp true, make sure outgoing UDP port 123 is open, and wait a minute.
chrony or systemd-timesyncd?
systemd-timesyncd is enough for an ordinary server and already ships with Ubuntu. Choose chrony when you need accuracy beyond a millisecond, when the server serves time to others, or when the network is unstable.
Summary
timedatectlis the main command: it shows local time, UTC, the zone and the synchronization state.- A zone is a "Continent/City" name set with
sudo timedatectl set-timezone; choose it by who reads the logs. - Servers with mixed users, or several machines, are easier to run on UTC.
systemd-timesyncdkeeps the accuracy; watchOffsetandSystem clock synchronized.- A wrong clock disguises itself as certificate,
apt, two-factor and cron errors.
🎁 40% off the first month of a new VPS. Promo code GUIDE40
Need a server for your tasks? The first month at a discount.
EnterGUIDE40at checkout. One use per customer.
Pick a VPS and claim the discount →
