Change timezone on Ubuntu 25.10 with timedatectl, then confirm that local time, UTC, and network synchronization still agree. You can finish the change over SSH in about five minutes, and the server does not need a reboot.
Prerequisites
- Ubuntu 25.10 (Questing Quokka) installed on the VPS.
- SSH access as
root, or a normal account that can run commands withsudo. - The destination timezone as an IANA name, such as
America/New_York,America/Los_Angeles, orAsia/Kolkata. - No special RAM, disk, or domain requirement; a VPSLake Linux VPS provides the Ubuntu server and administrator access needed here.
Step 1: Inspect the current time settings
Record the current zone and synchronization state first so you can tell a display change from a clock that is actually inaccurate.
timedatectl status
timedatectl show --property=Timezone --property=NTPSynchronized
date -u '+UTC: %F %T %Z'
date '+Local: %F %T %Z %z'A fresh VPS often starts in UTC. The date will differ on your machine, but the important fields should look similar to this:
Local time: Thu 2026-10-08 10:30:00 UTC
Universal time: Thu 2026-10-08 10:30:00 UTC
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
Timezone=Etc/UTC
NTPSynchronized=yes
UTC: 2026-10-08 10:30:00 UTC
Local: 2026-10-08 10:30:00 UTC +0000The timezone only changes how software presents the current instant. NTPSynchronized=yes tells you that a time service is keeping that instant accurate.
Step 2: Find the exact IANA timezone
Ubuntu uses the tzdata database, so choose a complete Region/City identifier instead of a label such as “Eastern Time” or an ambiguous abbreviation like EST.
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/LondonIf you need to browse every installed choice, run the following and press q when you are finished:
timedatectl list-timezones | lessUse a city-based zone because it includes the location’s daylight-saving rules. Select UTC when logs and scheduled maintenance should use one stable reference time regardless of where operators are located.
Step 3: Set the Ubuntu 25.10 timezone
Apply the setting through systemd so the running system and persistent /etc/localtime link are updated together.
sudo timedatectl set-timezone YOUR_REGION/YOUR_CITYReplace YOUR_REGION/YOUR_CITY with the exact entry from Step 2, such as America/New_York or Asia/Kolkata. A successful command normally prints nothing. Read back the saved name and its zoneinfo target:
timedatectl show --property=Timezone --value
readlink -f /etc/localtime
date '+Local: %F %T %Z %z'For America/New_York, output will resemble this; the timestamp and daylight-saving abbreviation depend on the date:
America/New_York
/usr/share/zoneinfo/America/New_York
2026-10-08 06:30:00 EDT -0400Do not edit /etc/localtime by hand or use date to force the clock to a local-looking value. The official timedatectl reference documents the timezone operations used here.
Step 4: Check Ubuntu’s time synchronization
Timezone selection and clock synchronization are separate, so confirm the service that maintains the underlying clock after changing the display zone.
systemctl is-active systemd-timesyncd
timedatectl timesync-statusOn a VPS using Ubuntu’s default synchronizer, you should see active followed by a report containing values like these:
active
Server: 91.189.89.198 (ntp.ubuntu.com)
Poll interval: 32s (min: 32s; max 34min 8s)
Leap: normal
Stratum: 2The server address, poll interval, and stratum vary. The useful signs are an active service and a normal synchronization state. Ubuntu’s server documentation for timedatectl and timesyncd explains how this default service works and notes that Chrony takes over if it is installed.
Verify the new Ubuntu 25.10 timezone
Run a final comparison that proves the selected zone is persistent and that local time represents the same instant as UTC.
timedatectl show --property=Timezone --property=NTPSynchronized
date -u '+UTC: %F %T %Z'
date '+Local: %F %T %Z %z'
readlink -f /etc/localtimeAfter choosing America/New_York, the result should have the same shape as this:
Timezone=America/New_York
NTPSynchronized=yes
UTC: 2026-10-08 10:30:00 UTC
Local: 2026-10-08 06:30:00 EDT -0400
/usr/share/zoneinfo/America/New_YorkYour timestamp will be different. The check passes when Timezone and the /etc/localtime target match your choice, while the local and UTC lines show the expected offset. Existing applications that deliberately use UTC can continue to display UTC.
Troubleshooting
Failed to set time zone: Invalid or unknown time zone
The argument is not an exact entry in the installed tzdata database. Run timedatectl list-timezones, copy the complete capitalization and slash-separated name, and retry. Do not use a Windows timezone name, a display label, or a three-letter abbreviation.
Authentication is required or Access denied
Changing the system-wide timezone is an administrative operation. Confirm the account can authenticate with sudo -v, add sudo to the command, or reconnect as root; changing permissions on /etc/localtime is not necessary.
systemd-timesyncd is inactive or NTPSynchronized=no
Another service such as Chrony may already own time synchronization, or the default package may not be enabled. Check for an active provider before starting a second daemon:
systemctl --type=service --state=running | grep -E 'chrony|timesyncd'
timedatectl statusIf neither service is present, restore Ubuntu’s built-in synchronizer:
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=NTPSynchronizedThe last command should eventually report NTP=yes and NTPSynchronized=yes. If it does not, inspect sudo journalctl -u systemd-timesyncd -n 30 --no-pager and make sure outbound UDP port 123 is allowed by any provider firewall or security group.
The host changed, but an application still shows UTC
The operating system may be correct while the application, container, database, or shell has its own timezone setting. Confirm the host with timedatectl show --property=Timezone --value, check for a TZ environment variable with env | grep '^TZ=', and follow the affected software’s configuration before restarting only that service.
Hardening and operational notes
- Keep infrastructure on
UTCwhen services span several regions; this makes logs and maintenance windows easier to correlate. - Review cron jobs after choosing a daylight-saving zone because a local-time schedule can move relative to UTC when the offset changes.
- Keep exactly one time-synchronization service in charge and avoid manually changing the clock with
date. - Ubuntu 25.10 is an interim release with support through July 2026; if this VPS is still running it, plan a supported-release upgrade before relying on it for long-term production work.
FAQ
What timezone should I use for a VPS in New York?
Use America/New_York, not EST. The IANA location includes the correct Eastern Time daylight-saving transitions, so the displayed abbreviation can change between EST and EDT as the calendar changes.
Does changing the timezone change the server’s actual clock?
No. timedatectl set-timezone changes the local representation of the current instant. The NTP service remains responsible for keeping that instant aligned with network time.
Do I need to reboot Ubuntu 25.10?
No. The timezone applies immediately and is persisted through /etc/localtime. Restart a particular service only when it explicitly caches timezone information at startup.
Why does a cron job run at a different UTC time after the change?
Cron normally interprets schedules in the system’s local timezone, so a daylight-saving zone can shift its UTC execution time. Use UTC for the host or configure the job and application with an explicit timezone when the global execution instant must remain fixed.
