OH 4.3.2 using wrong time zone

I just migrated my operative system from OH 4.3M1 to OH 4.3.2 Release. Everything went fine except for the time zone.

I have my system set up as follows…

  • RasPi v4 Linux time timedatectl => Europe\London
  • openhabian-config | 30 | 30 => Europe\London
  • OH Main UI | Settings | Regional Settings => Europe\London

And the result is as follows…

  • Linux console => shows correct time
  • OH Main UI log viewer => shows correct time
  • OH log file entries => time stamp is actual local time PLUS one hour
  • OH rules cron trigger => trigger fires at actual local time PLUS one hour

Any thoughts?


PS

  • I tried setting OH Main UI | Settings | Regional Settings => Europe/Dublin in case it is a Brexit thing.
  • I also tried OH Main UI | Settings | Regional Settings => Atlantic/Azores (UK Time minus 1 hour) in case I needed to over compensate.

However neither of these changed anything. The OH log file entries time stamp resolutely remain as actual local time PLUS one hour.

I also tried clearing browser cache. And also tried a different browser. Neither had any impact.


At 19:12: local London time I went on a ‘world tour’ … this is what I see in the logs…

2025-01-31 20:12:30.805 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to 'Europe/Dublin'.
2025-01-31 20:13:36.048 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to 'Europe/Berlin'.
2025-01-31 20:13:51.967 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to 'America/New_York'.
2025-01-31 20:14:06.974 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to 'Asia/Singapore'.
2025-01-31 20:14:23.821 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to 'Europe/London'.

Maybe this:

Many thanks for the suggestion. But no that did not work.

PS when I reboot OH I see the following in the log. Note that the actual time was ‘19:37’ and the first log entry (before setting the time zone) said ‘20:37’ and the log entries after setting the time zone also say ‘20:37’ …

2025-01-31 20:37:40.416 [INFO ] [org.openhab.core.Activator          ] - Starting openHAB 4.3.2 (Release Build)
2025-01-31 20:37:41.707 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to 'Europe/London'.
2025-01-31 20:37:41.725 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Location set to '52.19551588354342,0.11028170585632326'.
2025-01-31 20:37:41.728 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Locale set to 'en'.
2025-01-31 20:37:41.731 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Measurement system set to 'SI'.

Did you restart openHab after making the change?

Yes

Check if your java process is running with some -Duser.timezone parameter like
-Duser.timezone=Europe/Berlin.
Eventually add yours to /etc/default/openhab (the line with EXTRA_JAVA_OPTS).

1 Like

Aha. So it is. @mstormi perhaps you have an idea why that might be? My system has always been home based in UK…

—-

@mstormi to be more specific: I wonder if we need to make any changes in openhabian-config | 30 | 33 or in OH Core | Regional Settings | Timezone to take into account resp. overrule such environment settings. => WDYT?

Question: why do we even need to set user.timezone for the JVM?
Wouldn’t setting /etc/timezone prior to starting up the JVM be sufficient?

I have been setting user.timezone for my JVM running inside docker for forever, but I’ve just tried taking it out and making sure /etc/timezone and /etc/localtime are both mapped from the host into docker, and that seems to be enough, without setting user.timezone.

There is only one place user.timezone seems to be set in the stock openhabian, and it’s hard-coded to Europe/London:
https://github.com/search?q=repo%3Aopenhab%2Fopenhabian%20user.timezone&type=code

Because without this, quite some people were hit by the opposite problem, running in UTC forever.
Looking at the code however seems that won’t be executed if you are not on ARM.
@AndrewFG are you?
cc @ndye

Is there a way we can replicate the problem that would lead to UTC (when user.timezone isn’t set)?

some subconscious wish to un-brexit? :rofl: SCNR.

2 Likes

I am on a RasPiV4

Indeed.

For me setting empty java options seems to work just fine…

EXTRA_JAVA_OPTS=

For the non-UTC rest of the world it did not.

didn’t it though?
My local timezone is UTC+10. I removed my -Duser.timezone from EXTRA_JAVA_OPTS and openhab is still showing the correct timezone in the logs and cron / datetimetrigger events fired off at the correct time

no that is why the code is there now.
Several people including myself had that problem.

I’d love to be able to reproduce this problem. Maybe Can I fire up openhabian on a VM?

Well you can install a bookworm debian and openHABian on top, however the problem is likely linked to how the OS/java pkg/… handles stuff, so less likely to reproduce the issue when you’re not on Raspi.

But @AndrewFG already confirmed that it’s working on RPi 4 without setting it in EXTRA_JAVA_OPTS?