For many administrators, setting the time on the server seems like a trivial matter - something that can be put off until later. Often, it is indeed put off until later - but only until the moment when a database backup “suddenly” shows a date from the future, an SSL certificate is marked as expired, and cron runs a task at a completely unexpected time.
Such problems can remain hidden for a long time. The server runs for weeks or months without a single complaint, and then a single incorrect time setting triggers errors in the logs, monitoring failures, strange application behavior, and questions that are difficult to answer at first glance. The consequences can be particularly severe in an infrastructure with multiple servers, containers, databases, and various services that constantly exchange data with one another.
Another point adds to the confusion: Timezone and NTP are often perceived as one and the same thing. In reality, these are completely different mechanisms, each responsible for its own part of time management.
In this article, we’ll break down these concepts and learn how to configure the time on your Linux server.
The Difference Between Timezone and NTP
To put it simply, the timezone determines how the server displays the time, while NTP ensures that this time matches reality.
You can think of a regular wall clock. The time zone determines what exactly will be displayed on the clock face for a specific region, while NTP periodically checks this clock against an accurate reference and adjusts it if it starts running fast or slow.
In Linux, the system time is stored in UTC. Users, applications, and event logs already receive the time adjusted for the selected time zone. This approach eliminates many problems, especially when a single server serves users from different countries or is located in a data center thousands of kilometers away from the project owner.
This is why there are two separate configuration steps.
- Select the correct time zone;
- Configure automatic time synchronization via NTP.
Skipping either of these steps is not a good idea, since, for example, the server might display the correct local time while actually being several minutes behind. The opposite can also happen, where the clock is perfectly accurate, but all events in the logs are recorded in a different time zone. Both scenarios will eventually lead to the problems described above.
Now that we’ve defined these concepts, let’s go through each one step by step using real-world examples.
How to check the current time zone
Most modern Linux distributions use systemd for time management. You can check the current settings with a single command:
timedatectl
Among other information, you’ll see a line with the time zone, for example:
Time zone: Europe/Kyiv (EEST, +0300)
If the server shows UTC or a different region instead of the correct one, it’s best to correct the time zone immediately; otherwise, you’ll later have to figure out why log entries, cron jobs, and notifications are coming in with strange times.
You can view the full list of available time zones like this:
timedatectl list-timezones
The list is quite long, so it’s easier to search for the desired region using a filter:
timedatectl list-timezones | grep Kyiv
To change the time zone, simply run this command:
timedatectl set-timezone Europe/Kyiv
After running this command, you won’t need to reboot the server, as the new time zone takes effect immediately, and most services start using it without any additional steps. Sometimes it’s helpful to check the time again using timedatectl, just to make sure the setting has actually been saved.
How to Check the Current Time and Synchronization
After setting the time zone, you should verify that the server displays the correct time and is actually synchronizing it with external sources. This is where issues that previously went unnoticed are most often discovered.
You can check the current system time with the command:
date
To get complete information about time settings, it’s more convenient to use another command:
timedatectl status
The timedatectl output contains several lines that are usually checked first:
Time zone System clock synchronized NTP service
These provide a quick overview of the overall situation, specifically which time zone is being used, whether the system clock is synchronized, and whether the NTP service is running at all.
Sometimes a situation arises where the server displays the correct local time, but the line System clock synchronized has the value no. This can confuse an administrator, since everything appears to be working properly on the surface. In reality, however, the clock is already gradually drifting from the correct time, and in a few weeks, this minor issue could easily turn into one of the problems described above.
If your server is a physical, dedicated server, or if your virtual machine has access to the host machine’s hardware clock, you can check its status separately using the command:
hwclock --show
The hardware clock (RTC or Real-Time Clock) is a separate timer on the motherboard that continues to run even after the system is shut down. When booting, Linux obtains the initial time from the RTC and then synchronizes it via NTP.
It’s worth remembering that computer clocks aren’t absolutely accurate. Any hardware timer will, sooner or later, begin to gradually deviate from standard time. Sometimes this amounts to fractions of a second per day, and sometimes to several seconds or minutes per month.
Most often, this issue is not relevant for VPS, since the hardware clock is hidden behind the hypervisor layer; however, on dedicated servers and home servers, an incorrect hardware clock can sometimes cause failures.
How NTP Works
NTP (Network Time Protocol) is responsible for time accuracy on the server.
This protocol periodically compares the local clock with reference sources of accurate time on the internet and corrects it as needed.
Sources can include specialized servers at universities, data centers, research organizations, or public time pools. The server queries them at set intervals, calculates the discrepancy, and applies corrections.
Interestingly, modern NTP clients typically do not jump the time forward or backward by several seconds at once. Such an approach could cause problems for applications, databases, and various services. Instead, the system gradually speeds up or slows down the clock until the discrepancy disappears.
Public time sources are suitable for most projects, for example:
pool.ntp.org 0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org
Alternative servers from popular companies like Google or CloudFlare are also frequently used:
time.google.com time.cloudflare.com
There are services where you can find an accurate time server by country and continent.
However, in most modern distributions, the list of servers is already configured by default, and manually changing it is usually only required in corporate networks or specific infrastructures.
As for the NTP client itself, there are two options most commonly used today: systemd-timesyncd and chrony.
systemd-timesyncd is part of systemd, requires virtually no configuration, and is well-suited for standard VPSes, since time synchronization works by default after OS installation - as they say, “out of the box.”
Chronyis considered a more feature-rich solution, as it achieves accurate time faster after startup, handles unstable network connections better, can act as its own NTP server, and offers more configuration options. Therefore, it is often used on high-load servers, in virtualized environments, and complex infrastructures.
In our case with a standard VPS, the difference between these tools is rarely noticeable to the untrained eye. So if your server hosts a simple website, an online store, corporate email, or a few simple containers, the standard systemd-timesyncdis perfectly sufficient. However, when maximum synchronization accuracy is required or when dealing with a large number of servers, Chronyis more commonly chosen.
Installing Chrony and Checking Synchronization
Since we’re writing a comprehensive article on time configuration and synchronization in Linux systems, let’s quickly go over how to install and use Chrony on a Linux server to complete the picture.
In Ubuntu and Debian, the installation looks like this:
apt update apt install chrony -y
In AlmaLinux, Rocky Linux, and CentOS:
dnf install chrony -y
After installation, you need to start the service and add it to autostart:
systemctl enable --now chronyd
After a few seconds, you can check the synchronization status:
chronyc tracking
The output will indicate which time source the server is using, the magnitude of any deviations, and whether the clock is currently synchronized.
A few more commands will come in handy for diagnostics.
List of time servers in use:
chronyc sources
Detailed statistics for each source:
chronyc sourcestats
General information about the synchronization status:
chronyc tracking
These commands often help faster than reviewing logs. Especially when you need to understand whether the server is receiving the current time, which source is selected as the primary one, and whether there is a noticeable discrepancy with the reference clock. Again, this rarely happens on a VPS, but after a virtual machine migration, network issues, or prolonged downtime, checking certainly won’t hurt.
How Docker Handles Time
It’s worth discussing time settings in a major infrastructure solution like Docker, as many people get confused by it. A container does indeed have its own time display, but it does not have its own clock.
By default, a container uses the host machine’s system time, so if the server’s time zone is set incorrectly or NTP synchronization is not working, the same issues will arise inside the containers.
You can check the current time directly:
docker exec -it container_name date
Usually, the result will match the time on the host. Exceptions are rare and are mainly related to specific container configurations or the replacement of timezone files.
Because of this, attempts to correct the time inside an individual container are usually pointless, and the cause should be sought at the server level. It is sufficient to configure the timezone and NTP on the host system, after which the changes will automatically affect all containers.
This is especially relevant in large microservice infrastructures where many containers operate, each responsible for its own area of work. One container writes logs, another processes queues, and a third works with the database. And if the time between them differs by even a few minutes, troubleshooting errors quickly turns into a nightmare. And when it comes to CI/CD, Docker clusters, or monitoring systems, correct time is no longer just a convenience but a technical necessity.
Let’s Summarize
So, setting the time on a Linux server usually takes a few minutes, so you should never neglect this during the initial server setup. The problem is that if you don’t do this, the consequences of errors may surface weeks or even months later, when the connection between the cause and the symptoms is no longer obvious, leading to a lengthy process of identifying the root cause and resolving the issue.
One of the most common mistakes when working with time is attempting to fix an inaccurate time on the server by simply changing the time zone.
The logic seems straightforward: the server is showing the wrong time, so you need to change the timezone. But in reality, the timezone only affects how the time is displayed. Therefore, if the system clock is running fast or slow, changing the timezone won’t fix anything.
Another common mistake is configuring multiple NTP clients on a single server. This can happen after updates, migrations, or an administrator’s experiments, when, for example, chronyd, ntpd, and systemd-timesyncdare all running simultaneously. Each of them tries to manage time according to its own rules. As a result, synchronization can be unstable, which most often manifests as time jumps.
There is also a simpler mistake. Or perhaps not even an error, but negligence: the NTP client is installed, the service is started, but checking the synchronization status is forgotten or deemed unnecessary. Then it turns out that the server was unable to connect to time sources due to network issues, a firewall, or incorrect configuration.
Therefore, after the initial setup, it’s always a good idea to spend another minute on a final check:
- the correct time zone is selected;
- automatic time synchronization is working;
- the
timedatectloutput showsSystem clock synchronized: yes; - the hardware clock (if used) shows the correct time;
- the system time matches the actual time.
That’s basically it.
Frequently Asked Questions
Should you use UTC on the server?
For international projects, UTC is often more convenient, but for small servers, you can use the local time zone.
Which is better for a VPS - Chrony or systemd-timesyncd?
For most VPSes, systemd-timesyncdis sufficient. However, if you need more precise synchronization and advanced diagnostics, then choose Chrony.
Can an incorrect time cause problems with SSL certificates?
Yes. If there is a significant time discrepancy, the certificate may be identified as invalid or expired.
Do I need to install NTP inside Docker containers?
Usually not, since containers use the host system’s time.
How often does the server synchronize time via NTP?
Automatically and regularly. The exact frequency depends on the NTP client being used.
What happens if NTP servers are temporarily unavailable?
The server will continue to use the current time, and synchronization will resume automatically once the connection is restored.
Conclusion
Setting the time on the server takes literally a few minutes, but it can save you from a long search for errors in the future.
The correct timezone helps you read logs correctly and understand exactly when a particular event occurred. And NTP ensures the accuracy of the system clock. If everything is configured correctly, then cron jobs run on time, SSL certificates work without surprises, and event logs don’t turn into a puzzle.
That’s why it’s best to set the time right away after installing a Linux server. It’s just as basic a procedure as configuring SSH access, a firewall, or backups.
