How to Change Timezone on Ubuntu 24.04 (Step-by-Step)

To change timezone on Ubuntu 24.04, choose an IANA location and apply it with timedatectl. The new local-time setting takes effect immediately, so you can update and verify a fresh VPS in about five minutes without a reboot.

Prerequisites

• Ubuntu 24.04 LTS (Noble Numbat) installed on the VPS.
• SSH access as root, or a regular account with working sudo privileges.
• The destination timezone as an IANA name, such as America/Chicago, America/New_York, or Asia/Kolkata.
• No special RAM, disk, or domain requirement; a VPSLake Linux VPS provides the Ubuntu server access needed for this change.

Step 1: Inspect the current clock settings

Check the existing timezone and synchronization state first so you have a clear before-and-after comparison.

timedatectl status
date '+Local: %F %T %Z %z'
readlink -f /etc/localtime

The date will differ on your server, but a new VPS using UTC may show output like this:

               Local time: Thu 2026-10-08 09:30:12 UTC
           Universal time: Thu 2026-10-08 09:30:12 UTC
                 Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
Local: 2026-10-08 09:30:12 UTC +0000
/usr/share/zoneinfo/Etc/UTC

timedatectl reports the system-wide setting, while /etc/localtime points to the zoneinfo data used by local-time calculations. Changing the timezone changes how an instant is displayed; it does not manually correct the underlying clock.

Step 2: Find the exact IANA timezone

Ubuntu expects a database identifier, not a label such as “Eastern Time” or a short abbreviation such as EST. List the installed choices and copy the complete spelling.

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

Typical results include:

America/Chicago
America/Los_Angeles
America/New_York
Asia/Kolkata
Asia/Singapore
Europe/London

If you already know the region, narrow the result. For example, this lists common US zones:

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

Use a city-based entry because it includes the location’s daylight-saving rules. Select UTC when logs and scheduled maintenance should use one fixed reference rather than local civil time.

Step 3: Apply the new timezone

Use systemd’s timezone interface so Ubuntu updates the running setting and the persistent /etc/localtime link together.

sudo timedatectl set-timezone YOUR_REGION/YOUR_CITY

Replace YOUR_REGION/YOUR_CITY with the exact value chosen in Step 2, such as America/Chicago or Asia/Kolkata. A successful command normally prints nothing. Read back the stored zone and formatted local time:

timedatectl show --property=Timezone --value
date '+%F %T %Z %z'

For America/Chicago, output will resemble this; the timestamp and seasonal abbreviation will vary:

America/Chicago
2026-10-08 04:30:12 CDT -0500

Do not edit /etc/localtime by hand or change the hardware clock to force a local display. The Ubuntu timedatectl manual documents the supported timezone operations.

Step 4: Check Ubuntu’s time synchronization

Timezone selection and clock synchronization are separate, so confirm that Ubuntu’s time service is still keeping the underlying clock accurate.

systemctl is-active systemd-timesyncd
timedatectl show --property=NTP --property=NTPSynchronized

On a fresh Ubuntu 24.04 VPS using the default synchronizer, the result should contain:

active
NTP=yes
NTPSynchronized=yes

The first command checks the service; the second checks whether NTP is enabled and has synchronized successfully. If another daemon such as Chrony is already managing time, leave systemd-timesyncd alone and verify that daemon instead—running two time synchronizers is counterproductive.

Verify the new Ubuntu 24.04 timezone

Compare the selected zone with UTC. Both date lines should describe the same instant while showing the appropriate local offset.

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

After selecting America/Chicago, expected output will look similar to this:

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

Your timestamp will be different. The setup is correct when Timezone matches the IANA name you chose and the UTC/local lines differ only by the expected offset. A service that deliberately uses UTC can still show UTC even when the host is configured correctly.

Troubleshooting

Failed to set time zone: Invalid or unknown time zone

The value is not an exact entry in Ubuntu’s installed timezone database. Run timedatectl list-timezones, copy the complete region and city name, and repeat the command. Do not use a Windows timezone label, spaces, or an abbreviation such as PST.

Authentication is required or Access denied

Changing the system-wide timezone requires administrator privileges. Confirm that sudo -v succeeds, add sudo to the set-timezone command, or reconnect as root; changing permissions on /etc/localtime is not necessary.

NTPSynchronized=no or systemd-timesyncd is inactive

The clock service may not be installed, enabled, or able to reach its time sources. First check whether another daemon is already in charge:

systemctl list-units --type=service --state=running | grep -E '(chrony|timesync|ntp)'

If no time daemon is running, restore Ubuntu’s default service:

sudo apt update
sudo apt install -y systemd-timesyncd
sudo timedatectl set-ntp true
sudo systemctl enable --now systemd-timesyncd
timedatectl show --property=NTP --property=NTPSynchronized

The final line should eventually report NTP=yes and NTPSynchronized=yes. If synchronization remains unavailable, inspect sudo journalctl -u systemd-timesyncd -n 30 --no-pager and confirm that outbound UDP port 123 is allowed by any provider firewall or security group.

The host changed, but an application still shows UTC

Many applications intentionally log in UTC, and some read the system timezone only at startup. Confirm the host with timedatectl show --property=Timezone --value, then check the application’s own timezone setting and restart only that service if its documentation requires it. Also look for a shell or service environment variable such as TZ.

Hardening and operational notes

• Use UTC for infrastructure that serves several regions; it makes logs easier to correlate and avoids ambiguous daylight-saving transitions.
• Review cron entries after selecting a daylight-saving zone because a local-time schedule can move relative to UTC during the year.
• Keep exactly one time-synchronization service enabled and avoid manually changing a production clock with date.
• Record the selected IANA identifier in your provisioning notes so a rebuild uses the same convention.

FAQ

Does changing the timezone change the VPS’s actual clock?

No. timedatectl set-timezone changes the way the current instant is rendered as local time. NTP remains responsible for keeping that instant aligned with network time sources.

Should I use America/New_York or EST for an East Coast server?

Use America/New_York. A full IANA name carries the region’s daylight-saving rules, while EST is only an abbreviation and can produce the wrong result during part of the year.

Will Ubuntu 24.04 need a reboot after the change?

No. The system-wide timezone applies immediately and persists through reboots. Restart an individual application only if it cached the previous timezone when it started.

Why does a cron job run at a different UTC time after the change?

Cron schedules normally use the server’s local timezone, so the same local hour can map to a different UTC instant when the offset changes. Use UTC-based scheduling when a job must run at one globally fixed time, and review jobs near daylight-saving transitions.