** Description changed:
+ [WORKAROUND FOR AFFECTED USERS]
+
+ /etc/timezone will be dropped entirely in Ubuntu 25.10. Please update
+ affected applications to use /etc/localtime instead of /etc/timezone.
+
+ Please see [1], and more specifically [2], if you need to keep
+ /etc/timezone up-to-date on Ubuntu 24.04 LTS.
+
+ [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
+
+
+ [Original 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
+ 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.
** Changed in: systemd (Ubuntu)
Status: New => Won't Fix
** Changed in: systemd (Ubuntu Noble)
Status: New => Won't Fix
** Changed in: systemd (Ubuntu Oracular)
Status: New => Won't Fix
--
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:
Won't Fix
Status in systemd source package in Noble:
Won't Fix
Status in systemd source package in Oracular:
Won't Fix
Bug description:
[WORKAROUND FOR AFFECTED USERS]
/etc/timezone will be dropped entirely in Ubuntu 25.10. Please update
affected applications to use /etc/localtime instead of /etc/timezone.
Please see [1], and more specifically [2], if you need to keep
/etc/timezone up-to-date on Ubuntu 24.04 LTS.
[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
[Original 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
