Had to install fresh a openhabian for OH 5 because of the 64 bit requirement. After importing the config from the old 32 bit system, the astro triggered rules used the wrong timezone. The system had Europe/London after installation. Changing this to Europe/Berlin (correct timezone) with timedatectl did not fix the rules triggering on Europe/London. openhabian-cli console outputs the wrong timezone after env. Changing -Duser.timezone=Europe/London to -Duser.timezone=Europe/Berlin in EXTRA_JAVA_OPTS fixes this but is tempory since it seems to get overwritten after a time. The UI timezone was and is set correctly and does not seem to affect the behaviour. How/where can I fix this permanently? Tx!
Based on what had been reported we don’t know what is changing the timezone. However, editing /etc/default/openhab has always been a permanent solution. I’ve not seen any reports where that doesn’t work.
The setting usually only gets messed with during an upgrade. If it’s changing under other circumstances something else is going wrong.
Tx for the quick reply! I have cleaned the cache (not sure that can have anything to do with it, but who knows?) and modified /etc/default/openhab again. I might have run OpenHab updates via openhabian-config after the last change of /etc/default/openhab, but that has never caused issues of this kind in the past (about five years on the old setup).
Nope, that will just cause OH to reinstall all the add-ons.
something changed in the 5.0 release time frame but we don’t know what. A close analysis of the relevant code doesn’t jive with the behavior. openHABian literally has three lines of bash script that sets the TZ in defaults to what is in /etc/timezone. So it’s a big mystery what could cause it to become something else.
In general problems seem to go away if the OS level TZ, default/openhab, and the TZ in MainUI → Settings → regional settings all match.
Interesting. timedatectl shows Europe/Berlin on my system, but /etc/timezone is Europe/London (which /etc/default/openhab switched back to without me doing anything). I’ve edited /etc/timezone to Europe/Berlin. Maybe that will help. Will keep you posted.
/etc/default/openhab is the file where the, well, default values are set. You can change it, but it will be changed during update/upgrade.
But there is another file to change these values, that is /etc/openhab/linux.parameters.
I don’t know when it was introduced, but you can check whether your system is aware of that file.
Just take a look at /etc/systemd/system/multi-user.target.wants/openhab.service:
[Unit]
Description=openHAB - empowering the smart home
Documentation=https://www.openhab.org/docs/
Documentation=https://community.openhab.org
Wants=network-online.target
After=network-online.target
[Service]
Environment=OPENHAB_HOME=/usr/share/openhab
Environment=OPENHAB_CONF=/etc/openhab
Environment=OPENHAB_RUNTIME=/usr/share/openhab/runtime
Environment=OPENHAB_USERDATA=/var/lib/openhab
Environment=OPENHAB_LOGDIR=/var/log/openhab
Environment=OPENHAB_STARTMODE=daemon
EnvironmentFile=-/etc/default/openhab # openHAB default values
EnvironmentFile=-/etc/openhab/linux.parameters # values set by user
User=openhab
Group=openhab
WorkingDirectory=/usr/share/openhab
ExecStart=/usr/share/openhab/runtime/bin/karaf ${OPENHAB_STARTMODE}
ExecStop=/usr/share/openhab/runtime/bin/karaf stop
SuccessExitStatus=0 143
RestartSec=5
Restart=on-failure
TimeoutStopSec=120
LimitNOFILE=102642
[Install]
WantedBy=multi-user.target
All parameters will be read from /etc/default/openhab, then from /etc/openhab/linux.parameters.
So the latter is higher priority, but if a parameter is not set, openHAB will use the value from default.
Please be aware that EXTRA_JAVA_OPTS is one parameter, so you have to copy the definition from /etc/default/openhab to /etc/openhab/linux.parameters if there are some additional settings (afaik depends on the platform).
Thanks for the detailed explanation. As /etc/detault/openhab was once more overwritten with the latest upgrade, I’ve checked, and yes, my system seems to be aware of the /etc/openhab/linux.parameters file (at least is listed in the openhab.service file). So I’ve created it and added the current version of the EXTRA_JAVA_OPTS (which again had Europe/London) modified to Europe/Berlin to it.
I can’t help but wonder how sustainable this approach is, given that there seems to be a need for OH upgrades to adjust the default EXTRA_JAVA_OPTS (at least this seems to be done on a regular basis), and for some reason appears to include the default timezone, so a simple appending of the timezone to the EXTRA_JAVA_OPTS via the linux.parameters file from the default version won’t help.
I guess one could sed one’s way out of this, but I can’t help but wonder if there is a reason to have the default EXTRA_JAVA_OPTS set the timezone independently at all instead of either pulling it either from system or UI settings?
Or is there possibly a persistant place not mentioned yet where the source of the timezone in the default EXTRA_JAVA_OPTS is pulled from during updates?
Edit: searched the OpenHub GitHub repo, Europe/London appears to be set in openhabian/build-image/openhabian.config , which also mentions that one should edit these settings using openhabian-config, which I had not tried. Tried this now, my openhabian-config currently sees Europe/Berlin. I nevertheless set this again there just to be sure. But still: this information has to come from somewhere and should be persistable across upgrades, I would think? Or do upgrades just overwrite everything with the defaults every time? Then many users should have seen this issue?
They did 
I’m not aware of anything like that. AFAIR the point was, that without any timezone setting, Java should set the timezone to the same as the underlying OS, but that did not work reliable.