Linux Timezone and NTP: A Server Time Setup Guide
How to set the timezone and NTP on a Linux server: timedatectl, UTC or local time, chrony and timesyncd, cron, logs, 2FA codes and Windows Server.

Contents
The server clock affects many things, from logs being in the right order and scheduled tasks running at the right time to SSL connections and two-factor authentication codes. Two things need to be right: the timezone (which region the server shows the time for) and the clock itself (synchronized with atomic time sources via NTP). Both can be set with a few commands.
This guide covers checking the clock on a Linux server, changing the timezone, choosing between UTC and local time, synchronizing with NTP and the problems a wrong clock causes.
Checking the clock: timedatectl
After connecting to your server over SSH, run:
timedatectl
The important lines in the output:
- Local time: The server's local time.
- Universal time: The UTC time.
- Time zone: The selected timezone, for example
Etc/UTCorEurope/Istanbul. - System clock synchronized: If it's
yes, the clock is being synchronized with NTP. - NTP service: If it's
active, the synchronization service is running.
Changing the timezone
To list the available timezones and pick one:
timedatectl list-timezones | grep Europe
sudo timedatectl set-timezone Europe/Istanbul
To switch back to UTC:
sudo timedatectl set-timezone Etc/UTC
After you change the timezone, cron jobs run according to the new timezone. You may need to restart applications and services that only read the timezone when they start.
UTC or local time?
| Situation | Recommendation |
|---|---|
| More than one server, in different regions | UTC |
| Users in different countries | UTC |
| A region that observes daylight saving time | UTC |
| A simple setup on a single server with tasks planned in local time | Local timezone |
UTC's biggest advantage is that the clock doesn't jump forward or back at daylight saving time changes; those jumps can make scheduled tasks run twice or not at all. The common approach in applications is to keep the server and the database in UTC and convert the time to the user's timezone when displaying it.
If your server is in UTC, set the times of your scheduled tasks accordingly; for example, if your local time is UTC+3, a job you want to run at 03:00 local time falls at 00:00 UTC. We cover the details of cron in our What is cron? article.
Time synchronization with NTP
NTP (Network Time Protocol) automatically synchronizes the server's clock with precise time sources on the internet. Because the clock can drift over time on virtual servers, keeping NTP on is especially important.
systemd-timesyncd (the default on Ubuntu and Debian):
sudo timedatectl set-ntp true
timedatectl timesync-status
The first command turns synchronization on, and the second shows which server it's synchronizing with and the status of the last synchronization.
chrony (the default on AlmaLinux and Rocky Linux, and installable on Ubuntu too):
sudo apt install chrony
chronyc tracking
chronyc sources
chronyc tracking shows how far the clock has drifted, and chronyc sources shows the time sources in use. When chrony is installed, it replaces systemd-timesyncd; don't run two synchronization services at the same time.
NTP connects out from the server over UDP port 123. If you use a firewall that restricts outgoing traffic, allow this connection; the details are in our How to use UFW guide.
What breaks if the clock is wrong?
- SSL and HTTPS: A server whose clock is far ahead or behind can think certificates aren't valid yet or have expired; outgoing HTTPS connections fail.
- Two-factor authentication: TOTP codes are based on time. If the clock drifts by a few minutes, the server rejects correct codes.
- Logs: When you compare logs from several servers and the clocks don't match, the order of events becomes impossible to follow.
- Scheduled tasks: Backups and maintenance jobs run at the wrong time.
- Databases and applications: Order, session and cache times are calculated incorrectly.
The clock on Windows Server
On Windows Server, you can change the timezone under Settings → Time & language. To check time synchronization and force a resync, open PowerShell as an administrator:
w32tm /query /status
w32tm /resync
If you're choosing between Windows Server and Linux, take a look at our Windows Server or Linux? article.
The clock on Nodesty servers
On Nodesty AMD Ryzen 9 9950X VPS and AMD EPYC 7763 VPS plans, you have full root access to set the timezone and NTP however you like. The 9950X plans are available in Frankfurt and New York; if you run servers in different regions, keeping them in UTC makes your logs and tasks consistent.
Frequently Asked Questions
Should the server clock be in UTC or local time?
If you have more than one server, users in different countries or a region that observes daylight saving time, UTC is safer; logs and timestamps stay comparable everywhere. For simple setups that run on a single server with scheduled tasks planned in local time, a local timezone can make things easier.
Does changing the timezone affect running applications?
When you change the system timezone, cron jobs start running according to the new timezone. Some applications only read the timezone when they start; you may need to restart those applications and services after the change. Records in the database don't change.
What happens if the clock is wrong?
Even a drift of a few minutes can cause certificate errors on SSL connections, rejected two-factor authentication codes, logs in the wrong order and scheduled tasks running at the wrong time. Always keep the clock synchronized automatically with NTP.
chrony or systemd-timesyncd?
For most servers, systemd-timesyncd, which comes preinstalled on Ubuntu and Debian, is enough. If you need more precise synchronization, multiple time sources or the server has to serve time to other devices, chrony is the more capable choice. AlmaLinux and Rocky Linux use chrony by default.
Which timezone does the database use?
MariaDB and PostgreSQL use the system timezone by default, but you can change this in their own settings. Storing timestamps in the database in UTC and converting them to the user's timezone when displaying them is the safest approach for applications with users in different regions.
Which timezone do Docker containers use?
Containers usually use UTC by default and don't automatically pick up the server's timezone. If a container needs a different timezone, you can set the TZ environment variable, for example TZ=Europe/Istanbul. The clock itself comes from the server, so you don't need to run NTP separately inside the container.
About the author
Nodesty Team · Infrastructure & Support
The Nodesty team runs our servers, network and DDoS protection day to day and answers customer support requests around the clock. These guides come from that work.
Related articles

How to Install Ollama: Run AI Models on Your Own Server
How to install Ollama and run AI models on your own server: setup, choosing a model and RAM, using the API, Open WebUI, secure access and CPU usage.

How to Install WordPress with Docker Compose
How to install WordPress with Docker Compose: MariaDB and WordPress containers, passwords in .env, Nginx and SSL, upload limits, backups and updates.

Server Monitoring: Tracking Resources, Services and Alerts
How do you monitor a server? What to watch, real-time monitoring with Netdata, external checks with Uptime Kuma, Prometheus and Grafana, alerts and logs.