UTC used instead of local timezone with ARM64 Docker image for openHAB 5.1.2

[dhwalker]

Summary

UTC is used instead of local timezone with ARM64 Docker image for openHAB 5.1.2. This effects trigger times for rules and comparisons with items like Daylight Start Time from Astro Sun Data. This does not happen with the Docker image for 5.1.1. This results in scripts running 16 hours late here in the America/Los_Angeles timezone. (I don't know if this does not happen in 5.1.2 without Docker.)

Expected Behavior

The correct timezone should be used.

Current Behavior

The UTC timezone is used. However...

dhwalker@rpi4b> docker exec d4df49409fdc date
Wed Feb 11 10:28:55 AM PST 2026
dhwalker@rpi4b> docker exec d4df49409fdc more /etc/timezone
::::::::::::::
/etc/timezone
::::::::::::::
America/Los_Angeles

Also, Blockly's "now" block returns "2026-02-11T09:57:00.347-08:00[America/Los_Angeles]"

Possible Solution

(Sorry...)

Steps to Reproduce

1. Create the following Blockly rule, changing the "When" time to a minute or two in the future:

2. Watch the log. The rule will not run until the specified time UTC, rather than the local timezone.

Context

I want to invoke rules at specific times and times relative to sunrise/sunset. Retreating to the Docker image for 5.1.1 has resolved the issue.

Your Environment

OpenSUSE does not create /etc/timezone automatically, so I create it with "timedatectl show --property=Timezone --value > /etc/timezone".

Image

• openHAB version: 5.1.2
• Image tag used: latest

Docker Host

• Operating System: openSUSE Tumbleweed (20260202)
• Docker Version: 28.5.1-ce, build f8215cc26
• Kernel Version: 6.18.8-1-default
• Architecture: aarch64

Configuration

I start openHAB with systemd:

[Unit]
Description=openHAB
Requires=docker.service
After=docker.service

[Service]
Restart=always
ExecStartPre=bash -c 'timedatectl show --property=Timezone --value > /etc/timezone'
ExecStart=/usr/bin/docker run --name=%n --net=host --pull=never --rm \
  -v /etc/localtime:/etc/localtime:ro \
  -v /etc/timezone:/etc/timezone:ro \
  -v /opt/openhab/conf:/openhab/conf \
  -v /opt/openhab/userdata:/openhab/userdata \
  -v /opt/openhab/addons:/openhab/addons \
  -v /opt/openhab/.java:/openhab/.java \
  --device=/dev/ttyACM0 \
  -e USER_ID=454 \
  -e GROUP_ID=460 \
  -e CRYPTO_POLICY=unlimited \
  -l diun.enable=true \
  -l diun.watch_repo=false \
  openhab/openhab:latest
ExecStop=/usr/bin/docker stop -t 2 %n
#ExecStop=/usr/bin/docker stop -t 2 %n ; /usr/bin/docker rm -f %n

# Restart the openhab process if it exits prematurely.
Restart=on-failure
RestartSec=20
StartLimitBurst=5
StartLimitInterval=60s

[Install]
WantedBy=multi-user.target

[digitaldan]

Hmm, thats odd, nothing has changed to the docker files in quite some time, i'm also in southern California and run our latest docker image with almost identical options in a compose file, but am not seeing this.

From inside my docker container

root@92346ec6a8e6:/openhab# ls -l /etc/localtime && cat /etc/timezone
lrwxrwxrwx 1 root root 27 Feb  1 16:00 /etc/localtime -> /usr/share/zoneinfo/Etc/UTC
US/Pacific

Its interesting /etc/localtime symlinks to UTC, and not /usr/share/zoneinfo/US/Pacific , but my time shows a Pacific time nonetheless in the container.

Could there be something else maybe misreporting the timezone?

[dhwalker]

Thanks for the quick reply!

I did some more research and found https://www.baeldung.com/java-jvm-time-zone, thinking that it's likely the JVM that's not getting the right timezone. Seeing that the TZ environment variable is the first suggested method to set the timezone for JVM, I check and found that TZ is not being set for either 5.1.2 or 5.1.1 (or the Docker host system). Nevertheless, I tried adding -e TZ=America/Los_Angeles to the docker run command for 5.1.2, and it worked. I guess something changed from 5.1.1 to 5.1.2 that resulted in a requirement for TZ.

I couldn't figure out a simple way to pass the hosts's timezone (America/Los_Angeles) through systemd and docker, but I may try again later. Under the assumption that others may run across this, though, adding something like:

if [ x${TZ} == "x" ] ; then
  export TZ=`cat /etc/timezone`
fi

to the container's startup would be nice.

[digitaldan]

So i spoke to soon! My docker container has the right time:

root@92346ec6a8e6:/openhab# date
Thu Feb 12 02:13:19 AM PST 2026

But obviously openHAB itself is on UTC

10:13:19.569 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'SolarEdge_2_Heat_Sink_Temperature' changed from 59.432 °F to 59.414 °F (source: org.openhab.core.thing$modbus:inverter-split-phase:solaredge2:40069:deviceInformation#heatsink-temperature)

So yes something changed here. I will check if this is something we need to fix here or in the core.

[wborn]

It probably has to do with that OH 5.1.1 uses Java 21.0.9 and OH 5.1.2 uses Java 21.0.10:

https://www.oracle.com/java/technologies/javase/21-0-10-relnotes.html

Changes to the Default Time Zone Detection on Debian-based Linux (JDK-8345213)

On Debian-based Linux distributions such as Ubuntu, the /etc/timezone file was previously used to determine the JDK's default time zone (TimeZone.getDefault()). According to Debian's Wiki, /etc/localtime is now the primary source for the system's default time zone, making /etc/timezone redundant. As a result, the JDK's default time zone detection logic has been updated to use /etc/localtime instead of /etc/timezone. If /etc/localtime and /etc/timezone are inconsistent for any reason, the JDK's default time zone is now determined solely based on /etc/localtime file.

[digitaldan]

Good find! Whats interesting as i mentioned above is that i have this in my compose file to mount my localtime ( i think this is from our docs)

- '/etc/localtime:/etc/localtime:ro'

where /etc/localtime is a standard symlink:
/etc/localtime -> /usr/share/zoneinfo/US/Pacific

but in the docker container this is symlinked to
/etc/localtime -> /usr/share/zoneinfo/Etc/UTC

So that mapping is not working 🤔

[wborn]

Looks like /etc/timezone is completely ignored now, see openjdk/jdk21u-dev@245ba28.

It seems to get the timezone info based on the symlink target.
E.g. if you add a script like this to /cont-init.d it works:

#!/bin/bash

rm -f /etc/localtime
ln -s /usr/share/zoneinfo/Europe/Amsterdam /etc/localtime

[digitaldan]

So i'm guessing that b/c /etc/localtime is a symlink, this never actually worked. We should probably update the docs to either use:

environment:
      - TZ=US/Pacific

and drop the localtime mapping

or, map the target of the symlink

volumes:
      - /usr/share/zoneinfo/US/Pacific:/etc/localtime:ro

wdyt?

[dhwalker]

It'd be nice if we didn't create yet another place where the timezone needs to be specified. In my case, I could do something like

-e TZ=`timedatectl show --property=Timezone --value`
 -or-
-v /usr/share/zoneinfo/`timedatectl show --property=Timezone --value`:/etc/localtime:ro

on the docker run command so the shell would insert the current host timezone, but it would be harder (at least at my level of understanding docker) when using compose.

I'm largely ambivalent on environment or volume. I don't know which is less likely to exhibit edge cases that don't work.