How to Change Timezone on CentOS Stream 9 (Step-by-Step)

To change timezone on CentOS Stream 9, select an IANA timezone and apply it with timedatectl. The new local time takes effect immediately, persists through reboots, and normally takes less than five minutes to configure over SSH.

Prerequisites

• CentOS Stream 9 installed on the VPS.
• SSH access as root, or a normal account with working sudo privileges.
• The target timezone as an IANA name, such as America/Chicago, America/Los_Angeles, or Asia/Kolkata.
• No special RAM, disk, or domain requirement; a VPSLake Linux VPS gives you the server access needed for this change.

Step 1: Record the current time settings

Check the current zone before changing it so you can separate a display change from a clock-synchronization problem.

timedatectl status
date '+Local: %F %T %Z %z'
date -u '+UTC: %F %T %Z'

The calendar values will differ on your server. A new VPS may report something similar to:

               Local time: Thu 2026-10-08 09:14:22 UTC
           Universal time: Thu 2026-10-08 09:14:22 UTC
                 RTC time: Thu 2026-10-08 09:14:21
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
Local: 2026-10-08 09:14:22 UTC +0000
UTC: 2026-10-08 09:14:22 UTC

The timezone changes how an instant is displayed. It does not manually set the server clock, and chronyd should continue to keep that clock aligned with network time.

Step 2: Find the correct IANA timezone

CentOS Stream 9 uses the system timezone database, so choose a complete region/city identifier rather than a label such as “Central Time” or an abbreviation like CST.

timedatectl list-timezones | grep -E '^(America|Asia|Australia|Europe)/'

Example results include:

America/Chicago
America/Los_Angeles
America/New_York
Asia/Kolkata
Australia/Sydney
Europe/London

If you already know the region, narrow the output:

timedatectl list-timezones | grep -E '^America/(Chicago|Denver|Los_Angeles|New_York)$'

For an unfiltered list, use timedatectl list-timezones | less and press q when finished. A city-based entry carries the daylight-saving rules for that location. Use UTC when you want one stable offset for infrastructure logs and scheduled maintenance.

Step 3: Apply the new timezone

timedatectl updates the running system and the persistent /etc/localtime configuration together, so you do not need to edit a zoneinfo file by hand.

sudo timedatectl set-timezone YOUR_REGION/YOUR_CITY

Replace YOUR_REGION/YOUR_CITY with the exact entry selected in Step 2, for example America/Chicago or Asia/Kolkata. A successful command normally prints nothing. Read back both the stored name and the resolved timezone file:

timedatectl show --property=Timezone --value
readlink -f /etc/localtime

For America/Chicago, the result should resemble:

America/Chicago
/usr/share/zoneinfo/America/Chicago

The systemd timedatectl documentation lists the supported timezone operations and output properties.

Step 4: Confirm Chrony still has the clock under control

Timezone selection and time synchronization are separate settings; check chronyd so a wrong clock is not blamed on the new offset.

systemctl is-active chronyd
systemctl is-enabled chronyd
chronyc tracking

On a synchronized host, the first commands should return active and enabled. The tracking report should contain values similar to:

Reference ID    : 192.0.2.25 (ntp.example)
Stratum         : 3
System time     : 0.000021 seconds fast of NTP time
Leap status     : Normal

The reference server and measured offset vary. The useful checks are an active service and Leap status : Normal. CentOS Stream 9 uses the chrony package and chronyd service for NTP; the RHEL 9 time configuration guide documents the same systemd and Chrony workflow.

Verify the new CentOS Stream 9 timezone

Run one final comparison of the exact zone, synchronization flag, local time, and UTC. The local and UTC lines should describe the same instant with different offsets.

timedatectl show --property=Timezone --property=NTPSynchronized
date '+Local: %F %T %Z %z'
date -u '+UTC:   %F %T %Z'

After choosing America/Chicago, expected output will look like this:

Timezone=America/Chicago
NTPSynchronized=yes
Local: 2026-10-08 04:14:22 CDT -0500
UTC:   2026-10-08 09:14:22 UTC

Your timestamp will be different. The configuration is correct when Timezone matches your chosen entry and NTPSynchronized=yes; a program that intentionally logs in UTC can still show UTC by design.

Troubleshooting

Failed to set time zone: Invalid or unknown time zone

The value is not an exact entry in the installed tzdata database. Run timedatectl list-timezones again and copy the complete spelling, including capitalization and underscores. Do not substitute a Windows timezone name, a display label, or a short abbreviation.

Authentication is required or Access denied

Changing the system-wide zone requires administrator rights. Check the account with sudo -v, add sudo to the command, or reconnect as root; changing permissions on /etc/localtime is unnecessary.

chronyc: command not found or chronyd is inactive

The Chrony package may be missing, or its service may have been stopped. Install it from the CentOS Stream repositories and enable the service:

sudo dnf install -y chrony
sudo systemctl enable --now chronyd
chronyc tracking

If tracking still has no usable source, inspect the recent service messages and confirm that the provider firewall allows outbound UDP traffic to NTP servers on port 123:

sudo journalctl -u chronyd -n 30 --no-pager
chronyc sources -v

date shows UTC after the change

First check timedatectl show --property=Timezone --value. If it reports your selected zone, the host setting is correct; the shell may have a TZ environment variable, or the application may deliberately use UTC. Check with env | grep '^TZ=', then inspect the affected service’s own timezone configuration.

A scheduled job runs at an unexpected hour

Cron interprets schedules using the system’s local timezone unless a job or application specifies another zone. Review jobs that run near daylight-saving transitions and use UTC in the schedule when the execution time must remain fixed globally.

Operational notes

• Use UTC for shared infrastructure when operators and users work across several regions.
• Keep chronyd enabled; changing a timezone should not involve manually setting the clock with date.
• Record the chosen IANA identifier in provisioning notes so a rebuild uses the same convention.
• Restart only an application that explicitly caches the system timezone at startup; a server reboot is not required.

FAQ

What timezone should I use for a Dallas VPS?

Use America/Chicago, which applies the Central Time rules used in Dallas. Confirm it appears in timedatectl list-timezones before applying it, and use UTC instead if the server is shared across regions.

Can I set CentOS Stream 9 to CST or PST?

Use a full IANA name such as America/Chicago or America/Los_Angeles. Abbreviations are ambiguous and do not express the complete seasonal rules for a location.

Will changing the timezone restart services or require a reboot?

No. The system setting changes immediately and remains in place after a reboot. A long-running application may need its own restart only if it read the old zone once during startup.

Does the timezone change alter NTP accuracy?

No. timedatectl changes the presentation of the current instant, while chronyd synchronizes the clock against network sources. Verify the two independently with timedatectl and chronyc tracking.