{"id":939,"date":"2026-10-27T13:00:00","date_gmt":"2026-10-27T13:00:00","guid":{"rendered":"https:\/\/vpslake.com\/blog\/?p=939"},"modified":"2026-10-27T13:00:00","modified_gmt":"2026-10-27T13:00:00","slug":"change-timezone-almalinux-9","status":"publish","type":"post","link":"https:\/\/vpslake.com\/blog\/2026\/10\/27\/change-timezone-almalinux-9\/","title":{"rendered":"How to Change Timezone on AlmaLinux 9 (Step-by-Step)"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Change timezone on AlmaLinux 9 with <code>timedatectl<\/code>, then confirm the selected IANA zone and network time status. The update is immediate and normally takes less than five minutes without a reboot.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Prerequisites<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n\n<li>AlmaLinux 9 installed and reachable through SSH.<\/li>\n\n\n<li>A <code>root<\/code> shell or a normal account with working <code>sudo<\/code> access.<\/li>\n\n\n<li>The destination timezone as an IANA identifier, such as <code>America\/Phoenix<\/code>, <code>Europe\/Paris<\/code>, or <code>Asia\/Kolkata<\/code>.<\/li>\n\n\n<li>No special RAM, disk, or domain requirement; a <a href=\"https:\/\/vpslake.com\/buy-vps\">VPSLake Linux VPS<\/a> provides the AlmaLinux server access needed for this task.<\/li>\n\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Step 1: Record the current setting<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Check the existing zone and clock synchronization first so you can tell a timezone change apart from an inaccurate system clock.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>timedatectl status\ndate '+Local: %F %T %Z %z'\ndate -u '+UTC: %F %T %Z'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The date will be different on your server, but the report should include the current zone and usually show an active NTP service:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>               Local time: Thu 2026-10-08 05:12:40 UTC\n           Universal time: Thu 2026-10-08 05:12:40 UTC\n                 Time zone: Etc\/UTC (UTC, +0000)\nSystem clock synchronized: yes\n              NTP service: active\nLocal: 2026-10-08 05:12:40 UTC +0000\nUTC: 2026-10-08 05:12:40 UTC<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Step 2: Find an exact IANA timezone<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">AlmaLinux 9 expects a zoneinfo name from its installed database, so select a complete region and city instead of guessing from an abbreviation.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>timedatectl list-timezones | grep -E '^(America|Asia|Australia|Europe)\/'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">For a specific choice, filter the list more narrowly:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>timedatectl list-timezones | grep -E 'America\/(Phoenix|Denver|Chicago|New_York)$'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Possible results look like this:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>America\/Chicago\nAmerica\/Denver\nAmerica\/New_York\nAmerica\/Phoenix<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Use the city-based identifier because it carries the region&#8217;s daylight-saving rules. A fixed label such as <code>PST<\/code> is not a complete timezone and can produce the wrong offset during part of the year. Choose <code>UTC<\/code> when you want server logs and scheduled work to follow one stable reference.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Step 3: Apply the AlmaLinux 9 timezone<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><code>timedatectl<\/code> updates the running system and the persistent <code>\/etc\/localtime<\/code> link together, avoiding manual edits to timezone files.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo timedatectl set-timezone YOUR_REGION\/YOUR_CITY<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Replace <code>YOUR_REGION\/YOUR_CITY<\/code> with the exact value from Step 2, for example <code>America\/Phoenix<\/code> or <code>Asia\/Kolkata<\/code>. A successful command normally prints nothing. Read back both the stored name and the zoneinfo target:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>timedatectl show --property=Timezone --value\nreadlink -f \/etc\/localtime<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">For <code>America\/Phoenix<\/code>, the result should resemble:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>America\/Phoenix\n\/usr\/share\/zoneinfo\/America\/Phoenix<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The <a href=\"https:\/\/www.freedesktop.org\/software\/systemd\/man\/latest\/timedatectl.html\" target=\"_blank\" rel=\"noopener\">official <code>timedatectl<\/code> documentation<\/a> describes the systemd command and its supported properties. You do not need to restart the server for this setting to persist.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Step 4: Keep chrony responsible for clock accuracy<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">AlmaLinux 9 uses <code>chronyd<\/code> for network time synchronization; changing the zone and synchronizing the clock are separate jobs.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>systemctl is-enabled chronyd\nsystemctl is-active chronyd\nchronyc tracking<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">On a healthy VPS, the first two checks should report <code>enabled<\/code> and <code>active<\/code>, and the tracking report should end with a normal leap status:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>enabled\nactive\nReference ID    : 192.0.2.20 (time.example)\nStratum         : 3\nSystem time     : 0.000014 seconds fast of NTP time\nLeap status     : Normal<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The reference address and measured offset will vary. The useful signals are an enabled, active service and <code>Leap status : Normal<\/code>. Do not run another time daemon alongside Chrony; consult the <a href=\"https:\/\/chrony-project.org\/documentation.html\" target=\"_blank\" rel=\"noopener\">Chrony documentation<\/a> if you need to diagnose its sources.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Verify the new timezone<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Run one final check that compares the selected zone with UTC while also confirming that systemd still sees the clock as synchronized.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>timedatectl show --property=Timezone --property=NTPSynchronized\ndate -u '+UTC:   %F %T %Z'\ndate '+Local: %F %T %Z %z'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">If you chose <code>America\/Phoenix<\/code>, the important lines should look similar to this:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Timezone=America\/Phoenix\nNTPSynchronized=yes\nUTC:   2026-10-08 05:20:40 UTC\nLocal: 2026-10-07 22:20:40 MST -0700<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The timestamps represent the same instant with different offsets. If the timezone name matches your choice and synchronization is <code>yes<\/code>, the AlmaLinux 9 host is configured correctly.<\/p>\n\n\n\n<aside class=\"vl-element vl-cta-banner\" aria-label=\"Deploy with the right timezone\">\n\t<div class=\"vl-cta-banner__content\">\n\t\t<p class=\"vl-cta-banner__eyebrow\">AlmaLinux VPS<\/p>\n\t\t<h3 class=\"vl-cta-banner__title\">Deploy with the right timezone<\/h3>\n\t\t<p class=\"vl-cta-banner__text\">Start with an AlmaLinux VPS and configure server time for your applications.<\/p>\n\t<\/div>\n\t<a class=\"vl-cta-banner__button\" href=\"\/buy-vps\" aria-label=\"View Linux VPS plans\">View Linux VPS plans<\/a>\n<\/aside>\n\n\n\n<h2 class=\"wp-block-heading\">Troubleshooting<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\"><code>Failed to set time zone: Invalid or unknown time zone<\/code><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The argument is not an exact zoneinfo identifier. Repeat <code>timedatectl list-timezones<\/code>, 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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><code>Access denied<\/code> or <code>Authentication is required<\/code><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Only an administrator can change the system-wide timezone. Test the account with <code>sudo -v<\/code>, add <code>sudo<\/code> to the <code>set-timezone<\/code> command, or reconnect as <code>root<\/code>; changing permissions on <code>\/etc\/localtime<\/code> is not required.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><code>chronyc tracking<\/code> cannot connect to daemon<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The Chrony package may be missing or <code>chronyd<\/code> may not be running. Inspect the unit and recent messages first:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>systemctl status chronyd --no-pager\njournalctl -u chronyd -n 30 --no-pager<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">If the service is not installed, restore the AlmaLinux package and start it:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo dnf install -y chrony\nsudo systemctl enable --now chronyd\nchronyc tracking<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">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 <code>chronyc sources -v<\/code> and the network path to the configured NTP servers.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">The displayed time moves by one hour later<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">That usually reflects daylight-saving rules, not a failed setting. Use a regional IANA name such as <code>America\/Denver<\/code> so the zone database can apply seasonal changes, or select <code>UTC<\/code> if the host should never shift its displayed offset.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Hardening and operational notes<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n\n<li>Use <code>UTC<\/code> for infrastructure serving multiple regions unless a job or business process explicitly needs local civil time.<\/li>\n\n\n<li>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.<\/li>\n\n\n<li>Keep <code>chronyd<\/code> enabled and avoid manually setting the clock with <code>date<\/code> on a production VPS.<\/li>\n\n\n<li>Record the chosen IANA identifier in your provisioning notes so a rebuild uses the same convention.<\/li>\n\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">FAQ<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Does <code>timedatectl set-timezone<\/code> change the server&#8217;s actual time?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Is <code>America\/Phoenix<\/code> a good choice for an Arizona server?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Yes. <code>America\/Phoenix<\/code> 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&#8217;s own IANA entry.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Will existing SSH sessions use the new timezone?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">New <code>date<\/code> 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.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Should I set a VPS to local time or UTC?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<script type=\"application\/ld+json\">{\"@context\": \"https:\/\/schema.org\", \"@type\": \"FAQPage\", \"mainEntity\": [{\"@type\": \"Question\", \"name\": \"Does `timedatectl set-timezone` change the server's actual time?\", \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"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.\"}}, {\"@type\": \"Question\", \"name\": \"Is `America\/Phoenix` a good choice for an Arizona server?\", \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"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.\"}}, {\"@type\": \"Question\", \"name\": \"Will existing SSH sessions use the new timezone?\", \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"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.\"}}, {\"@type\": \"Question\", \"name\": \"Should I set a VPS to local time or UTC?\", \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"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.\"}}]}<\/script>\n\n","protected":false},"excerpt":{"rendered":"Change timezone on AlmaLinux 9 with timedatectl, choose a valid IANA zone, preserve chrony sync, and verify the change without restarting the server.","protected":false},"author":1,"featured_media":940,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_singular_sidebar":"","csco_page_header_type":"","csco_page_load_nextpost":"","footnotes":""},"categories":[5,9],"tags":[95,109,108,107],"class_list":["post-939","post","type-post","status-publish","format-standard","has-post-thumbnail","category-guides","category-vps-hosting","tag-almalinux-9","tag-chrony","tag-timedatectl","tag-timezone","cs-entry"],"_links":{"self":[{"href":"https:\/\/vpslake.com\/blog\/wp-json\/wp\/v2\/posts\/939","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vpslake.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vpslake.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vpslake.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vpslake.com\/blog\/wp-json\/wp\/v2\/comments?post=939"}],"version-history":[{"count":1,"href":"https:\/\/vpslake.com\/blog\/wp-json\/wp\/v2\/posts\/939\/revisions"}],"predecessor-version":[{"id":3756,"href":"https:\/\/vpslake.com\/blog\/wp-json\/wp\/v2\/posts\/939\/revisions\/3756"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/vpslake.com\/blog\/wp-json\/wp\/v2\/media\/940"}],"wp:attachment":[{"href":"https:\/\/vpslake.com\/blog\/wp-json\/wp\/v2\/media?parent=939"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vpslake.com\/blog\/wp-json\/wp\/v2\/categories?post=939"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vpslake.com\/blog\/wp-json\/wp\/v2\/tags?post=939"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}