How to Change the Timezone on a Linux Server Using the Terminal

How to Change the Timezone on a Linux Server Using the Terminal

When you deploy a fresh Linux server — whether on Nanohost or anywhere else — the default timezone is often set to UTC. While UTC is a great choice for distributed systems, monitoring stacks, and logs, it may not be ideal for everyday usage, especially if you want your server’s local time to match your own. Setting the correct timezone makes logs easier to read, simplifies cron schedules, and avoids confusion when working with applications that rely on local time. Fortunately, Linux provides straightforward tools to update the timezone directly from the terminal, without requiring a reboot. In this article, we’ll walk through how Linux handles timezones, why it matters, and how to safely change the timezone on most modern distributions.

Understanding How Timezones Work on Linux

Linux stores timezone information using the IANA timezone database — the same global standard used by modern operating systems and cloud platforms. Instead of manually handling time offsets (like UTC+1 or UTC−3), Linux uses region-based identifiers such as Europe/Lisbon, America/New_York, or Asia/Singapore. These identifiers are more reliable because they automatically account for daylight saving changes and political adjustments. For example, if a country changes its DST policy, the IANA database will reflect this, and your server will follow the updated rules without requiring code modifications.

On most distributions, the active timezone is simply a symbolic link (/etc/localtime) pointing to a file inside /usr/share/zoneinfo. Understanding this structure is helpful: by adjusting that link, you’re effectively telling Linux which timezone rules to apply. You don’t need deep system-administration knowledge to manage these settings, and the process is quick as long as you know the correct timezone name.

Checking the Current Timezone

Before making any changes, it’s good practice to check what timezone your server is currently using. This helps you confirm whether a change is actually necessary and ensures you understand the starting point.

You can do this by running:

timedatectl

This command, available on all systemd-based distributions (Ubuntu, Debian, CentOS, Rocky Linux, Fedora, etc.), displays detailed time configuration: current date, local time, universal time (UTC), NTP synchronization status, and — importantly — the timezone in use. If your server is new, you will likely see something like Time zone: Etc/UTC, indicating that UTC is the default.

Listing Available Timezones

Before choosing a new timezone, it’s helpful to explore which ones are available. Linux ships with a comprehensive list of timezones under the IANA database, so you can pick the one that best matches your location or the region where your clients operate.

You can list all supported timezones by running:

timedatectl list-timezones

This will output hundreds of entries, grouped by regions such as Africa, America, Asia, Europe, and so on. It’s often easiest to use grep to filter the list:

timedatectl list-timezones | grep Lisbon

or

timedatectl list-timezones | grep Europe

Once you find the correct region string — for example, Europe/Lisbon — you’re ready to set it as the new timezone.

Changing the Timezone on a Linux Server

Modern Linux distributions allow you to change the timezone with a single command. The simplest way is to use timedatectl, which handles the symbolic link to /etc/localtime automatically and ensures consistency across the system.

To set a new timezone:

sudo timedatectl set-timezone Europe/Lisbon

There is no need to restart the server — the change takes effect immediately. You can verify the update by running timedatectl again and checking the “Time zone:” line. Additionally, running date will show you the updated local time.

Under the hood, this command updates /etc/localtime to point to the correct zoneinfo file. This design makes the process safe and reversible. If you ever need to change the timezone again — for example, because a project moves to a new region — simply run the same command with a different timezone string.

Manual Method (For Non-Systemd Distributions)

While systemd is now standard across most Linux distributions, some environments — particularly older systems, embedded distributions, or minimal container images — may not have timedatectl available. In such cases, you can still update the timezone by manually adjusting the /etc/localtime file.

First, confirm that the target timezone file exists:

ls /usr/share/zoneinfo/Europe/Lisbon

Then replace /etc/localtime with a symlink to this file:

sudo ln -sf /usr/share/zoneinfo/Europe/Lisbon /etc/localtime

And optionally store the timezone name manually:

echo "Europe/Lisbon" | sudo tee /etc/timezone

This method achieves the same result, but you should only rely on it when the systemd approach is unavailable.

Ensuring Correct Time Synchronization (Optional but Recommended)

Changing the timezone affects how the server displays time, but it doesn’t influence the accuracy of the clock itself. To ensure your server maintains accurate time, it’s important to have NTP (Network Time Protocol) enabled. Most modern distributions enable systemd-timesyncd or another NTP service by default.

You can check this with:

timedatectl show | grep NTPSynchronized

If synchronization is disabled, enabling it is as simple as:

sudo timedatectl set-ntp true

Accurate time is crucial for many tasks — from TLS certificates to database replication to log timestamps — so it's always wise to double-check that NTP is active.

Why Timezone Configuration Matters

While configuring a timezone may seem like a small detail, it plays a significant role in system administration. For example, if you’re managing cron jobs, their schedules are interpreted according to the server’s local time. An incorrectly configured timezone might cause scripts to run at unexpected hours. Similarly, logs stamped with the wrong timezone make troubleshooting more difficult, especially if you are correlating events across multiple services.

For global teams, setting the server to your local timezone can help match your workflow, while for distributed systems, leaving servers on UTC might be preferable. The key is understanding the impact and choosing the configuration that aligns with your operational needs.