[Bug 2103839] Re: timedatectl set-timezone does not update /etc/timezone, leaving system with inconsistent time zone setting

Nick Rosbrook 2103839 at bugs.launchpad.net
Thu Apr 3 17:34:52 UTC 2025 

** 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
Foundations Bugs, 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

More information about the foundations-bugs mailing list