Server Time and Time Zones: Why Your Clock Matters and How to Set It

The system clock is easy to ignore until it causes a strange problem. Logs that do not line up with the event you are investigating, a scheduled job that runs an hour late, a certificate that browsers say is "not yet valid", two-factor codes that never work: all can be traced to a clock that is wrong or a time zone nobody thought about. Fortunately, getting this right takes about five minutes on a new server.

Time, time zone and synchronisation are three separate things

• The clock counts time internally. Linux keeps it as an absolute moment, independent of any time zone.
• The time zone is only a rule for displaying that moment as local time, including daylight saving changes.
• Synchronisation keeps the clock accurate by comparing it with reference servers using NTP (Network Time Protocol). Without it, a virtual machine's clock drifts.

Mixing these up is the source of most confusion. You can change the displayed zone freely, and it never changes the underlying moment in time.

Check the state and set the time zone

Check the current state

timedatectl
date
date -u

timedatectl shows local time, UTC, the configured time zone and, importantly, whether the clock is synchronised (look for "System clock synchronized: yes" and the NTP service status). date -u prints UTC regardless of the zone.

Set the time zone

List the available names and set yours:

timedatectl list-timezones | grep Europe
sudo timedatectl set-timezone Europe/Berlin

Use a named region such as Europe/Berlin rather than a fixed offset, because names carry daylight saving rules. Berlin is only an example; choose the zone that makes sense for you.

Which zone should a server use? Many administrators choose UTC for every server. UTC has no daylight saving changes, so logs from servers in different places can be compared directly, and scheduled jobs never skip or repeat an hour twice a year. Local time on the server can help when your team reads logs without converting, but you pay for it with twice-yearly oddities. Whatever you choose, use the same setting on all your servers and document it.

Turn on time synchronisation

Most modern distributions include a time sync service. On Ubuntu and Debian, systemd-timesyncd is a lightweight client that is often enabled by default. Check and enable it with:

sudo timedatectl set-ntp true
timedatectl timesync-status

Some systems, notably Red Hat style distributions, use chrony instead, which is more precise and handles unreliable clocks better:

sudo apt install chrony        # Debian/Ubuntu
sudo systemctl enable --now chronyd   # service is "chrony" on Debian/Ubuntu
chronyc tracking

On Debian and Ubuntu the chrony service is named chrony, while on AlmaLinux and Rocky it is chronyd. The chronyc tracking output shows how far the system clock is from the reference. Run only one time-sync service; installing chrony normally replaces timesyncd.

What goes wrong when time is off

• TLS and certificates. Validity is checked against the clock. A server whose time is far off can reject valid certificates or issue confusing errors, and Let's Encrypt validation can fail.
• Two-factor codes. Time-based one-time passwords depend on both sides agreeing on the time within a short window.
• Logs and forensics. If servers disagree by minutes, reconstructing an incident across them becomes guesswork.
• Cron and scheduled tasks. Jobs run in the system's zone. Daylight saving changes can cause jobs to be skipped or run twice if scheduled in the transition hour.
• Distributed systems. Databases and caches with expiry times, tokens with expiry claims and cookies all rely on reasonably accurate time.

Handling time zones in applications and a checklist

The server setting is only part of the picture. A robust application follows a few rules:

1. Store timestamps in UTC in the database, using a proper timestamp type, and convert to the user's zone only when displaying.
2. Set the language runtime's zone explicitly. In PHP, set date.timezone in php.ini (for example to UTC); WordPress keeps its own timezone setting in its general settings. In Python, use timezone-aware datetime objects; in Node.js, rely on UTC internally and use Intl for display.
3. Know your database's zone. MySQL and MariaDB have a server time zone and a session setting that affect NOW() and TIMESTAMP columns; PostgreSQL has a TimeZone parameter. Check them instead of assuming.
4. Send emails and show reports with a clear zone label, so recipients in other regions are not misled.

A short checklist for every new server

1. Run timedatectl and confirm synchronisation is active.
2. Set the time zone, ideally UTC, and note the choice in your documentation.
3. Align PHP, database and application time zone settings with that choice.
4. Reboot once and recheck that the settings persisted.
5. Add the clock offset to your monitoring if you run more than a few servers.

Time zones and your users

Remember that the server's zone and your visitors' zones are different matters. A booking system, a countdown or a scheduled newsletter should store a precise moment and show it in each visitor's own zone, or state the zone clearly. Avoid saving local times without a zone, since they become ambiguous twice a year when clocks change. The knowledge base has more server setup guidance.

Correct time on your Zebra Hosting server

On managed plans the server clock is looked after for you. If you run your own VPS, apply the checklist above on day one.