How to Change Timezone on AlmaLinux 9 (Step-by-Step)

Change timezone on AlmaLinux 9 with timedatectl, then confirm the selected IANA zone and network time status. The update is immediate and normally takes less than five minutes without a reboot.

Prerequisites

• AlmaLinux 9 installed and reachable through SSH.
• A root shell or a normal account with working sudo access.
• The destination timezone as an IANA identifier, such as America/Phoenix, Europe/Paris, or Asia/Kolkata.
• No special RAM, disk, or domain requirement; a VPSLake Linux VPS provides the AlmaLinux server access needed for this task.

Step 1: Record the current setting

Check the existing zone and clock synchronization first so you can tell a timezone change apart from an inaccurate system clock.

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

The date will be different on your server, but the report should include the current zone and usually show an active NTP service:

               Local time: Thu 2026-10-08 05:12:40 UTC
           Universal time: Thu 2026-10-08 05:12:40 UTC
                 Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
Local: 2026-10-08 05:12:40 UTC +0000
UTC: 2026-10-08 05:12:40 UTC

The timezone changes the representation of an instant. It does not set the clock itself, so do not use a timezone change as a substitute for time synchronization.

Step 2: Find an exact IANA timezone

AlmaLinux 9 expects a zoneinfo name from its installed database, so select a complete region and city instead of guessing from an abbreviation.

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

For a specific choice, filter the list more narrowly:

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

Possible results look like this:

America/Chicago
America/Denver
America/New_York
America/Phoenix

Use the city-based identifier because it carries the region’s daylight-saving rules. A fixed label such as PST is not a complete timezone and can produce the wrong offset during part of the year. Choose UTC when you want server logs and scheduled work to follow one stable reference.

Step 3: Apply the AlmaLinux 9 timezone

timedatectl updates the running system and the persistent /etc/localtime link together, avoiding manual edits to timezone files.

sudo timedatectl set-timezone YOUR_REGION/YOUR_CITY

Replace YOUR_REGION/YOUR_CITY with the exact value from Step 2, for example America/Phoenix or Asia/Kolkata. A successful command normally prints nothing. Read back both the stored name and the zoneinfo target:

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

For America/Phoenix, the result should resemble:

America/Phoenix
/usr/share/zoneinfo/America/Phoenix

The official timedatectl documentation describes the systemd command and its supported properties. You do not need to restart the server for this setting to persist.

Step 4: Keep chrony responsible for clock accuracy

AlmaLinux 9 uses chronyd for network time synchronization; changing the zone and synchronizing the clock are separate jobs.

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

On a healthy VPS, the first two checks should report enabled and active, and the tracking report should end with a normal leap status:

enabled
active
Reference ID    : 192.0.2.20 (time.example)
Stratum         : 3
System time     : 0.000014 seconds fast of NTP time
Leap status     : Normal

The reference address and measured offset will vary. The useful signals are an enabled, active service and Leap status : Normal. Do not run another time daemon alongside Chrony; consult the Chrony documentation if you need to diagnose its sources.

Verify the new timezone

Run one final check that compares the selected zone with UTC while also confirming that systemd still sees the clock as synchronized.

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

If you chose America/Phoenix, the important lines should look similar to this:

Timezone=America/Phoenix
NTPSynchronized=yes
UTC:   2026-10-08 05:20:40 UTC
Local: 2026-10-07 22:20:40 MST -0700

The timestamps represent the same instant with different offsets. If the timezone name matches your choice and synchronization is yes, the AlmaLinux 9 host is configured correctly.

Troubleshooting

Failed to set time zone: Invalid or unknown time zone

The argument is not an exact zoneinfo identifier. Repeat timedatectl list-timezones, copy the complete spelling including its capitalization and underscore characters, and run the command again. Do not use a Windows timezone name, a display label, or a three-letter abbreviation.

Access denied or Authentication is required

Only an administrator can change the system-wide timezone. Test the account with sudo -v, add sudo to the set-timezone command, or reconnect as root; changing permissions on /etc/localtime is not required.

chronyc tracking cannot connect to daemon

The Chrony package may be missing or chronyd may not be running. Inspect the unit and recent messages first:

systemctl status chronyd --no-pager
journalctl -u chronyd -n 30 --no-pager

If the service is not installed, restore the AlmaLinux package and start it:

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

The server also needs outbound UDP port 123 through any provider firewall or security group. If the unit is active but has no usable source, check chronyc sources -v and the network path to the configured NTP servers.

The displayed time moves by one hour later

That usually reflects daylight-saving rules, not a failed setting. Use a regional IANA name such as America/Denver so the zone database can apply seasonal changes, or select UTC if the host should never shift its displayed offset.

Hardening and operational notes

• Use UTC for infrastructure serving multiple regions unless a job or business process explicitly needs local civil time.
• Review cron schedules after selecting a daylight-saving zone; a job defined in local time can run at a different UTC instant when the offset changes.
• Keep chronyd enabled and avoid manually setting the clock with date on a production VPS.
• Record the chosen IANA identifier in your provisioning notes so a rebuild uses the same convention.

FAQ

Does timedatectl set-timezone change the server’s actual time?

No. It changes how the system renders the current instant as local time. Chrony remains responsible for keeping that instant aligned with network time sources.

Is America/Phoenix a good choice for an Arizona server?

Yes. America/Phoenix is the IANA zone for most of Arizona and normally stays on Mountain Standard Time instead of following the usual daylight-saving change. If your users or business rules are in another region, select that region’s own IANA entry.

Will existing SSH sessions use the new timezone?

New date commands in an existing shell use the updated system setting immediately. A long-running service may retain its own timezone choice until you change its configuration or restart that service.

Should I set a VPS to local time or UTC?

UTC is usually easier for correlating logs and scheduling work across regions. Use local time when a customer-facing schedule or legal process depends on civil time, and configure the application and scheduler consistently.