After looking at this further, I think this is the best we can do for noble.
Among other things, the reason the downstream patch that supported /etc/timezone in systemd was dropped is that it was difficult to keep correct as the locations in the codebase which referenced /etc/localtime grew/changed. While other components may use /etc/timezone, that file is owned by tzdata, and so that package is responsible for updating the contents. I think pointing to this[1] discourse post, and in particular this[2] comment, is the best way to document the expected behavior. [1] https://discourse.ubuntu.com/t/how-to-change-the-time-zone-in-ubuntu-using-the-command-line/35307 [2] https://discourse.ubuntu.com/t/how-to-change-the-time-zone-in-ubuntu-using-the-command-line/35307/2 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2103839 Title: timedatectl set-timezone does not update /etc/timezone, leaving system with inconsistent time zone setting Status in systemd package in Ubuntu: New Status in systemd source package in Noble: New Status in systemd source package in Oracular: New Bug description: In Ubuntu 24.04 server, setting the system time zone via systemd's timedatectl fails to update the contents of /etc/timezone. In previous LTS server releases, timedatectl updated this file without any issue, so this is new faulty behavior. Because there are several different ways to query for the system's time zone (e.g., timedatectl, /etc/localtime, /etc/timezone), this bug leaves the system time zone in an inconsistent state, with the answer depending on the query method. For example, I discovered this bug when installing the latest version of Jenkins on Ubuntu 24.04, where Jenkins insisted my server was on UTC even though timedatectl would report back "America/Chicago". It turned out that Jenkins was reading the system time zone from /etc/timezone, which had never been updated after I set the timezone via timedatectl. I don't know for certain, but I believe that /etc/timezone is a common way for Java-based applications to read the system time zone. I think there has been talk of removing /etc/timezone entirely from Debian, since it could be considered redundant, which may be why timedatectl has changed its behavior here. I would be fine with that solution except for the fact that when I delete /etc/timezone on Ubuntu 24.04, it keeps getting recreated. I believe whenever the tzdata package is updated, that regenerates /etc/timezone, and a "dpkg-reconfigure tzdata" certainly does. If nothing else, there is an inconsistency in Ubuntu 24.04 between the behavior of timedatectl and the behavior of tzdata, and this inconsistent behavior can lead to an inconsistent time zone setting. Steps to reproduce the bug: ``` $ timedatectl show --property=Timezone Timezone=America/New_York $ ls -la /etc/localtime lrwxrwxrwx 1 root root 36 Mar 21 21:46 /etc/localtime -> /usr/share/zoneinfo/America/New_York $ cat /etc/timezone America/New_York $ sudo timedatectl set-timezone 'America/Chicago' $ timedatectl show --property=Timezone Timezone=America/Chicago $ ls -la /etc/localtime lrwxrwxrwx 1 root root 35 Mar 21 20:51 /etc/localtime -> /usr/share/zoneinfo/America/Chicago $ cat /etc/timezone America/New_York $ sudo dpkg-reconfigure --frontend noninteractive tzdata 2> /dev/null $ cat /etc/timezone America/Chicago ``` ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: systemd 255.4-1ubuntu8.5 ProcVersionSignature: Ubuntu 6.8.0-55.57-generic 6.8.12 Uname: Linux 6.8.0-55-generic x86_64 ApportVersion: 2.28.1-0ubuntu3.3 Architecture: amd64 CasperMD5CheckResult: pass Date: Fri Mar 21 18:20:28 2025 InstallationDate: Installed on 2025-02-11 (38 days ago) InstallationMedia: Ubuntu-Server 24.04.1 LTS "Noble Numbat" - Release amd64 (20240827) Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: MachineType: VMware, Inc. VMware7,1 ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.8.0-55-generic root=UUID=d1d2bd07-2fa1-4f46-b54e-6b249e25a778 ro SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/07/2020 dmi.bios.vendor: VMware, Inc. dmi.bios.version: VMW71.00V.16707776.B64.2008070230 dmi.board.name: 440BX Desktop Reference Platform dmi.board.vendor: Intel Corporation dmi.board.version: None dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 1 dmi.chassis.vendor: No Enclosure dmi.chassis.version: N/A dmi.modalias: dmi:bvnVMware,Inc.:bvrVMW71.00V.16707776.B64.2008070230:bd08/07/2020:svnVMware,Inc.:pnVMware7,1:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:sku: dmi.product.name: VMware7,1 dmi.product.version: None dmi.sys.vendor: VMware, Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2103839/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
