Fedora 45 reached general availability on November 3, 2026, with GNOME 51, KDE Plasma 6.8 and kernel 7.2. The fastest way to change its timezone is sudo timedatectl set-timezone Region/City. GNOME Settings and a manual symlink to /usr/share/zoneinfo also work, and the right choice depends on whether you have a desktop, a headless server or a container.

A wrong timezone causes more trouble than most people expect. Cron jobs fire an hour early. Log entries don’t line up with the monitoring dashboard. A certificate renewal script runs at what looks like the wrong time, and a customer reports an invoice stamped with tomorrow’s date. None of it is dramatic on its own, but each one costs real time to debug, and the cause is usually a timezone nobody checked at provisioning.

Fedora makes the change simple because it uses systemd. One tool, timedatectl, handles the timezone, the clock and NTP synchronization. The details still matter, though. You need to know where the setting is stored, how it differs from the hardware clock, what happens to services that are already running, and when UTC is the better answer.

This guide covers the command line and the desktop, then the manual method, and then the edge cases: servers, containers, dual boot and per-application overrides. It ends with troubleshooting and a short list of habits that save trouble later. The examples use Asia/Jakarta (WIB, UTC+7), but any valid zone name works the same way.

How Timezones Work on Fedora

Fedora doesn’t keep timezone rules in one config file. The rules live in the tz database under /usr/share/zoneinfo, which holds a compiled file for each region. The active zone is whichever file /etc/localtime points to. In practice /etc/localtime is a symbolic link, and that link is the whole setting.

The Fedora CoreOS documentation describes it the same way. Available zones are tzfile entries under /usr/share/zoneinfo, and the timedatectl command displays and sets the date, time and timezone. The mechanism has been stable for years, so a command from an old Fedora guide will almost always still work.

System clock vs hardware clock

Linux tracks two clocks. The system clock is maintained by the kernel and is what applications read. The hardware clock (RTC) is the battery-backed clock on the motherboard, used at boot to seed the system clock. Most Linux installs keep the RTC in UTC and convert to local time in software. That’s the right design, because it means a timezone change never touches the stored hardware time.

Windows historically stores local time in the RTC, which causes the classic dual-boot clock drift. That scenario gets its own section below.

Why UTC is often the right answer

On a single-location desktop, setting the local zone is natural. On servers it is usually a mistake. A fleet spread across regions, a database replicating between data centers and an ELK stack ingesting logs from several hosts all become easier to reason about when every machine runs UTC. Daylight saving transitions cause a further problem. A local zone can produce a 2:30 AM that doesn’t exist in spring or occurs twice in autumn, and cron jobs scheduled in that window behave unpredictably.

Indonesia has no daylight saving, so WIB is stable. A server in Yogyakarta serving local users can sensibly run Asia/Jakarta. A server that talks to the world should probably stay on UTC and convert at the presentation layer. The rest of this guide applies either way.

Check the Current Timezone First

Before changing anything, record the current state.

timedatectl

Typical output on a fresh install:

               Local time: Tue 2026-11-10 05:17:42 UTC
           Universal time: Tue 2026-11-10 05:17:42 UTC
                 RTC time: Tue 2026-11-10 05:17:42
                Time zone: UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Look at four lines. “Time zone” is what you’re changing. “System clock synchronized” tells you whether NTP is working. “NTP service” shows whether systemd-timesyncd or another service is running. “RTC in local TZ: no” is what you want on Linux.

To see where the link points:

ls -l /etc/localtime

Output like /etc/localtime -> ../usr/share/zoneinfo/UTC confirms the active zone independently of timedatectl. This check is useful when something looks inconsistent, since it reads the file directly.

Method 1: Change Timezone With timedatectl

This is the standard method. It works on Fedora Workstation, Server, KDE, Cloud and IoT editions, and it’s scriptable.

Step 1: Find the exact zone name

Zone names follow the Region/City format and are case-sensitive in some tools. List them all:

timedatectl list-timezones

The list is long, so filter it. The Fedora documentation uses the same approach, piping the list through grep for a region:

timedatectl list-timezones | grep -i asia
timedatectl list-timezones | grep -i jakarta

Pick the city that shares your rules, not necessarily the one nearest you. Yogyakarta has no entry of its own, so Asia/Jakarta (WIB) is correct. Use Asia/Makassar for WITA and Asia/Jayapura for WIT.

Step 2: Set the timezone

sudo timedatectl set-timezone Asia/Jakarta

The command produces no output when it succeeds. That silence confuses people the first time, so verify:

timedatectl

You should now see Time zone: Asia/Jakarta (WIB, +0700). The local time line updates immediately, and the Universal time line stays the same, because the underlying instant never changed. Only the display rule did.

Step 3: Confirm with date

date
date -u

The first prints local time with the zone abbreviation. The second prints UTC. The two should differ by exactly seven hours for WIB.

Switching back to UTC

sudo timedatectl set-timezone UTC

Use this when you’re standardizing servers or preparing a machine for a multi-region deployment.

Method 2: Use the GNOME Settings GUI

Fedora Workstation ships GNOME, and the graphical route is fine for laptops.

1. Open Settings.
2. Choose System, then Date & Time.
3. Turn off Automatic Time Zone if you want to choose manually.
4. Click Time Zone and search for your city, or click the map.
5. Close the dialog. The change applies instantly.

Automatic timezone detection

GNOME can set the zone from your location. That’s handy for people who travel, since the laptop adjusts when they land. It does depend on location services, so if you’ve disabled those for privacy, the automatic setting won’t work. Sysadmins with a laptop that doubles as a jump box often turn it off, so that log timestamps from SSH sessions stay consistent.

KDE Plasma users get the equivalent under System Settings, then Date & Time. The result is identical, since both desktops call the same systemd service in the background.

Method 3: Change the Symlink Manually

Sometimes timedatectl isn’t available. Examples are minimal containers, a chroot during recovery, or a rescue environment. In those cases the symlink method works because it is what timedatectl does internally.

sudo ln -sf /usr/share/zoneinfo/Asia/Jakarta /etc/localtime

The -s flag creates a symbolic link and -f replaces the existing one. Check the result:

ls -l /etc/localtime
date

The Fedora CoreOS documentation also notes that the link can be absolute or relative to a tzfile entry. If /usr/share/zoneinfo is missing, install the data package:

sudo dnf install tzdata

Why a copy is a bad idea

Some old tutorials suggest cp /usr/share/zoneinfo/Asia/Jakarta /etc/localtime. Avoid it. A copied file is frozen, so when the tzdata package updates because a government changed its rules, your copy stays stale. A symlink follows the update automatically. Governments do change timezone rules, and tzdata updates ship regularly for that reason.

Does the Change Apply to Running Services?

Mostly yes, but not always. A process that has already loaded timezone data into memory may keep using the old zone until it restarts. Typical examples:

• Long-running daemons that call tzset() once at startup.
• Java applications, which read the zone at JVM start.
• PHP-FPM workers, if date.timezone is set in php.ini, because that overrides the system zone.
• PostgreSQL and MySQL, which each have their own timezone setting.

After changing the zone on a live server, restart the services that matter:

sudo systemctl restart crond
sudo systemctl restart rsyslog
sudo systemctl restart httpd

On Fedora the cron service is crond, from the cronie package. Check for yours with systemctl status crond. The journal itself stores timestamps in UTC internally and converts on display, so journalctl shows the new zone straight away.

Checking what a process sees

systemctl show --property=Environment nginx
sudo cat /proc/$(pidof nginx | awk '{print $1}')/environ | tr '\0' '\n' | grep -i TZ

If a TZ variable appears, it overrides /etc/localtime for that process. This is a classic gotcha, because someone set it years ago and forgot.

Per-Application and Per-User Timezones

Not everything should follow the system zone. Linux lets you override it narrowly.

The TZ variable

TZ=America/New_York date

This affects only that command. It’s a fast way to check what a timestamp means for a colleague in another region without touching the system. For a whole shell session:

export TZ=Europe/London

Add that to ~/.bashrc to make it persistent for one user. Don’t confuse it with the system zone, because timedatectl will keep reporting the system value.

Systemd services

For a single service, add an environment override:

sudo systemctl edit myapp.service

Then add:

[Service]
Environment=TZ=Asia/Jakarta

Save, then reload and restart:

sudo systemctl daemon-reload
sudo systemctl restart myapp.service

This pattern fits a legacy app that must report local time while the host stays on UTC. It’s cleaner than changing the whole machine.

Containers and Podman on Fedora 45

Fedora 45 ships Podman 6, and containers are a frequent source of timezone confusion. A container doesn’t automatically inherit the host zone. Most images default to UTC.

The simplest fix is the TZ variable:

podman run --rm -e TZ=Asia/Jakarta fedora:latest date

This only works if the image contains tzdata. Minimal images often don’t, and in that case the variable silently does nothing. Alternatively, mount the host’s localtime read-only:

podman run --rm -v /etc/localtime:/etc/localtime:ro fedora:latest date

Podman also accepts --tz=local to match the host. In a Containerfile, bake the zone in:

FROM fedora:latest
RUN dnf -y install tzdata && ln -sf /usr/share/zoneinfo/Asia/Jakarta /etc/localtime

For production, many teams keep containers on UTC and let the application format times for users. It avoids a whole class of “works on my machine” bugs.

NTP and Time Synchronization

Setting the right zone is pointless if the clock itself is wrong. Check synchronization:

timedatectl status | grep -i synchronized

If NTP is off, turn it on:

sudo timedatectl set-ntp true

Fedora typically uses systemd-timesyncd or chrony. Chrony is the better choice for servers because it handles unstable networks and large offsets gracefully, and it gives you diagnostics:

sudo dnf install chrony
sudo systemctl enable --now chronyd
chronyc tracking
chronyc sources -v

chronyc tracking reports the offset from the reference. On a healthy production host you’d expect it in the low milliseconds. Large offsets after a timezone change usually mean the clock was already wrong, and the new zone just made it more visible.

Setting time by hand

You can only set the time manually when NTP is disabled:

sudo timedatectl set-ntp false
sudo timedatectl set-time "2026-11-10 12:30:00"

Remember that this is interpreted in the current local zone. Set the zone first, then the time. Doing it in the other order is a common way to end up seven hours off.

Dual Boot With Windows

Dual-booting is where timezone trouble is most visible. Windows assumes the hardware clock holds local time. Linux assumes UTC. Boot one and then the other, and the time jumps by your UTC offset.

There are two fixes. The cleaner one is to make Windows use UTC by adding a registry value (RealTimeIsUniversal, a DWORD set to 1) under the TimeZoneInformation key. The alternative is to tell Linux to use local time:

sudo timedatectl set-local-rtc 1 --adjust-system-clock

Systemd warns that local RTC mode has limitations, particularly around daylight saving changes, so prefer the Windows registry change when you can. Indonesia doesn’t observe DST, so the Linux-side workaround is less risky for WIB users than for someone in Europe or North America.

Troubleshooting Common Problems

“Failed to set time zone: Invalid time zone”

The name is wrong. Zone names are Region/City, and spelling matters. Asia/Jogjakarta fails, while Asia/Jakarta works. Run timedatectl list-timezones | grep -i <keyword> to find the exact string.

“Failed to connect to bus” or “Access denied”

You’re missing privileges, or you’re in an environment without systemd, such as some containers and chroots. Prefix with sudo. Inside a chroot, use the symlink method instead.

The zone changed, but applications show the old time

Restart the service. Check for TZ overrides, and check application-level settings like PHP’s date.timezone, Java’s -Duser.timezone flag, or the database’s own timezone parameter. System settings never override explicit application config.

The time is right, but the date is off after a reboot

This points to a dual-boot RTC mismatch or a dead CMOS battery. Check timedatectl for “RTC in local TZ”. If the battery is dying, the clock resets to a default date on each power loss. NTP will correct it after boot, but the interval before sync can break certificate validation and log ordering.

/etc/localtime is a regular file, not a link

Someone copied the file. Replace it:

sudo rm /etc/localtime
sudo timedatectl set-timezone Asia/Jakarta

Verify with ls -l /etc/localtime that it’s a link again.

NTP shows as “inactive” or the clock won’t sync

Check the service and firewall:

systemctl status chronyd
sudo firewall-cmd --list-all

NTP uses UDP port 123 outbound. Strict egress rules on a locked-down server can block it. Allow outbound traffic to your time sources and test again with chronyc sources.

SELinux complaints

If you place custom files and see denials, restore contexts:

sudo restorecon -v /etc/localtime

Symlinks created with ln normally inherit sensible labels, but a manual copy from another directory can carry the wrong one.