JDK-8345213 : JVM Prefers /etc/timezone Over /etc/localtime on Debian 12
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 21
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux_debian_3.0
  • CPU: generic
  • Submitted: 2024-11-27
  • Updated: 2025-03-07
  • Resolved: 2025-02-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 25
25 b12Fixed
Related Reports
Relates :  
Sub Tasks
JDK-8350686 :  
Description
ADDITIONAL SYSTEM INFORMATION :
Java Version: OpenJDK 17 & 21
OS: Debian GNU/Linux 12 (bookworm)

A DESCRIPTION OF THE PROBLEM :
In recent versions of Debian (starting with Debian 12), the system no longer relies on /etc/timezone for timezone management. Instead, Debian and systemd have transitioned to using /etc/localtime as the authoritative source for timezone data. However, OpenJDK still prioritizes /etc/timezone when determining the system timezone, leading to inconsistencies between the system's timezone and the default timezone for the JVM.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Set the system timezone using timedatectl: "sudo timedatectl set-timezone Europe/Paris"
2. Check /etc/localtime and /etc/timezone: "ls -l /etc/localtime; cat /etc/timezone"
    Observe that /etc/localtime points to /usr/share/zoneinfo/Europe/Paris, but /etc/timezone has not been updated.
3. Run a simple Java application and retrieve the default timezone:

    System.out.println(java.util.TimeZone.getDefault());
 
    Observe that the JVM reports the timezone from /etc/timezone

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Java should use /etc/localtime as the primary source for determining the system timezone, consistent with Debian’s new standard.
ACTUAL -
Java uses /etc/timezone, causing mismatches between the system timezone and the JVM timezone.

CUSTOMER SUBMITTED WORKAROUND :
Explicitly specifying the timezone with the "TZ" variable or "-Duser.timezone" JVM option.

or

Manually updating /etc/timezone after changing the systems timezone with "timedatectl":
timedatectl show --value --property=Timezone | sudo tee /etc/timezone

FREQUENCY : always



Comments
Changeset: c8a521fd Branch: master Author: Naoto Sato <naoto@openjdk.org> Date: 2025-02-25 23:03:18 +0000 URL: https://git.openjdk.org/jdk/commit/c8a521fddac9d42fe93ea9b3ab89e804bc48bf4e
25-02-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/23755 Date: 2025-02-24 19:46:52 +0000
24-02-2025

Additional Information from submitter: ================================ Providing some documentation to Debian removing support for the /etc/timezone file: - https://wiki.debian.org/TimeZoneChanges#Check_Configured_Timezone - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822733#35 - https://tracker.debian.org/news/1424576/accepted-systemd-2526-1-source-into-unstable/ - https://salsa.debian.org/systemd-team/systemd/-/blob/8ce52334d889fc0a85d0fc00a6ed93c8030b6426/debian/NEWS
17-02-2025

Can the submitter point to me the documentation of the Debian's change? From what I understand, conflicting /etc/timezone and /etc/localtime is the source of the problem. I will re-open this issue once I confirmed that the conflicting /etc/timezone and /etc/localtime on Debian is indeed the expected behavior (IMO, timedatectl command should make those files in consistent state, otherwise such erratic behavior would happen not only with the JDK)
02-12-2024

Successfully reproduced the issue using Ubuntu 24.04.1 LTS against the most recent JDK tip.
02-12-2024

The observations on WSL 2: JDK 21: Passed. Failed to run timedatectl on debian:bookworm container because of the following error: System has not been booted with systemd as init system (PID 1). Can't operate.
30-11-2024