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?