with OH running on current Openhabian/Raspberry 4 I have problems with the timezone since updating to 5.1. This happened first with 5.1.1 and persists with the 5.1.2 update I did yesterday.
Both the system and OH are set to “Europe/Madrid”.
Output at the prompt
openhabian@openhabian:/var/log/openhab $ timedatectl Local time: Do 2026-02-12 12:08:33 CET Universal time: Do 2026-02-12 11:08:33 UTC RTC time: n/a Time zone: Europe/Madrid (CET, +0100) System clock synchronized: yes NTP service: active RTC in local TZ: no
However, I not only see that the logfile is one hour behind (i.e. as set to “UTC”), also the cron triggers are using this “wrong” time. So it looks as OH is not taking the TZ into account.
And regarding the 5.1 version in general I’m honestly feeling a little discomfort. There were a couple of things causing little issues, concerning sitemaps, strange log entries that suddenly disappearead after multiple cache cleans and restarts, a bug in the astro binding and now the timezone thing. Have to say, upgrades went much smoother with earlier version, so with 5.2 I will definitly wait until the final release of the 5.2 series will be out before performing the next upgrade.
There are several threads discussing this issue. the tl;dr is:
for quite some time now, sometimes during an upgrade, something is overwriting /etc/default/openhab with the wrong tyimezone. Sometimes it’s set to London, other times it’s set to Berlin.
we don’t know what’s doing this. A review of all the code that does this shows it merely copies the value from /etc/timezone when necessary.
The fix is to edit /etc/default/openhab and add your timezone to the EXTRA_JAVA_OPS variable. The comments in this file tell you how to do that.
thanks a lot, that solved the problem perfectly! I tried to find a topic beforehand but actually was not able to find one in the forum, sorry for bringing it up the n-th time now
I also can confirm that my /etc/timezone is set to “Europe/Madrid” but the java config setting were set to “Europe/London”. So at least in my case the source for the setting was coming from somewhere else.
Have to say I wasn’t aware about this setting(s) at all, especially with the setting in the UI one can assume everything is set. But I also understand from own experience that date/locale/TZ settings can be quite weird in unix as there’s alsways a myriad of possibilities to get the config from.
My experience was it was intermittent. If you can reliably reproduce it you might be able to figure out what is writing to the file so it can be fixed.
I cannot confirm “timezone keeps resetting”: On my installation it was definitly the first time. However it might have been overwritten, maybe just this time with the wrong value so I have never notified this before even if it has been overwritten. I did not take a full SD backup unfortunately, so otherwise I could replay the upgrade. But will try to next time.
