I had the situation that the timezone in regional settings was different then the timezone configured in “-Duser.timezone”. My question is, how to deal with it from a developer perspective.
e.g. pythonscripting relies on JVM default timezone. That means that the regional settings are completely ignored. If a enduser is not aware of it, it results in unexpected behaviors. He configured “Europe/Berlin” in openhab, but for some reason the startup setting was ‘-Duser.timezone=Europe/London’ and he was thinking that pythonscripting has the wrong timezone.
I have now 2 options.
Fix/overwrite the default timezone in my binding with the value of the regional setting. Maybe with a warning.
Just print a warning to show that pythonscripting is running with the timezone of ‘user.timezone’ then the regional setting and explain the consequences.
I personally would prefer solution 2, because solution 1 would maybe fix most of the usecases, but still it just hides to root cause by fixing the symptom.
Next thing is that I have the feeling that my binding is the wrong place for it. It should be handled in I18nProviderImpl
What do you think? Anyone with openhab core dev background has an option?
I know this problem from the openHABian OS perspective. There’s an already huge amount of
OS settings that affect timezone, and they’re all different depending on the OS a user chooses and what he already knows about timezone configuration possibilities and what (s)he is used to using.
In the end, the user is and will remain responsible to ensure that any eventual -Duser.timezone setting matches with what he configures as regional settings, simple as that.
If he doesn’t, it doesn’t make sense to attempt working around this in code, so: just don’t.
Would just lead to more unexpected and hard to interpret behavior.
This is how I’m doing it currently with the pythonscripting binding. The question is, if we should have this kind of warning in a more central place and not only in my binding.
btw. in my binding I have no additional workaround, I just show a warning about this issues to create awareness for the user
I don’t think 1 is viable because the problem lies outside the python add-on. And if the Java timezone and OS timezones don’t match that means the user is going to experience other unexpected problems beyond just the python add-on.
There are tons of threads on the forums with users running into this issue. It would be nice if we could come up with some universal solution but what ever it is should probably be done in core or openhab-distro.
Despite the number of threads that have come up though, I don’t think we have a good idea why some users run into this problem while others do not. But what I do know is that usually, Java picks up the timezone from the OS. But only when the -Duser.timezone isn’t supplied. But when and how the -Duser.timezone gets set is hidden from the end users. Does apt/yum set that? Does only openHABian set that? (though this is a question that could be answered).
Most frustrating of all is the one place where the timezone is presented to the end user in MainUI → Settings → Regional settings does not seem to have any impact on what timezone OH actually operates under at all. I’m not even really certain why that option is there.
This is a long way to say this is and has remained a problem since OH 2.0 and a fix for it would be fantastic! But I don’t think individual add-ons should attempt to fix it piecemeal. I don’t see any problem with logging a warning. Though implementing that warning in core would be even better.
The only problem with this approach is that the user is ill equipped to do this. The one place where the user can obviously see to change the timezone has no practical effect. “user.timezone” appears nowhere in the OH docs (or at least it doesn’t show up with a search). openHABian has a way to set the timezone from the start, but that doesn’t help apt/yum/manual et al. users. Docker users pass the localtime and timezone files into the container and omits the -Duser.timezone command line property, but sometimes we still need to set the -Duser-timezone command line argument through an environment variable.
I put my comment on this topic here. I simultaneously opened another thread, which I will delete.
So here is my comment:
We had a longer discussion here about the timezone settings that are in
Linux system
Java options
openHAB
While I was trying to use some java.time.ZonedDateTime functions or even normal Python datetime functions in the Python Scripting, we found out that the system everywhere had the correct timezone (Europe/Berlin) configured, but in the EXTRA_JAVA_OPTS in /etc/default/openhab there was -Duser.timezone=Europe/London. And Python scripting seemed to use this one by java.time.ZoneId.systemDefault().getId()). Therefore, in the script timezone was set incorrectly.
I then corrected it in the file, which did not directly help, but after some add-on installations and openHAB restarts back and forth the incorrect timezone was gone.
Then I removed two add-ons, installed the Python Scripting Add-on again and the incorrect timezone was back again, but now after a clean-cache it is gone.
It is worth to mention that in JS Scripting, there are no native Java time classes, and JS-Joda uses other means to get the system default, therefore it is plausible that it does not happen there.
As Holger is sure that this behavior has nothing to do with the Python Scripting Add-on itself, I open a separate discussion here with the questions:
How can the -Duser.timezone setting for Java be influenced during the setup or installation process?
Can it be harmonized / synchronized with the openHAB or system settings for timezone?
When there are timezone discrepancies they appear ouside of scripts too. For example log timstamps are off, cron triggers happen at the wrong time, etc.
But joda-js gets the time from GraalVM same as python does, I suspect.
In openHABian you can set the timezone in the openhabian.conf file read during that first boot. For Docker -Duser.timezone is not set at all. The instructions have you mount /etrc/localtime and /etc/timezone into the container so the container is configured to the same time as the host. But you can add Java extra opts like this as an environment variable.
For everyone else I don’t think you can. You have to do it manually after the fact.
That’s the big question. By default Java is supposed to get the timezone from the operating system. However, you can override that by supplying the -Duser.timezone extra opt. Sometimes it appears that getting the timezone from the operating system doesn’t work and the only way to get it right is to supply the -Duser.timezone extra opt. When and why that fails
I can’t see how that would be the case. There is no file in temp nor the cache that refer to the timezone. /etc/default/openhab isn’t part of the cache.
This problem has been around for many many years. I’ve personally looked into it more than once. If I had any good ideas I would have tried to fix it before now. But there isn’t enough information to figure out why Java fails to get the timezone in the first place and/or the installers fail to set the proper timezone in /etc/default/openhab in the first place.
I did and placed Europe/Berlin there, but nevertheless I later found -Duser.timezone=Europe/London in the EXTRA_JAVA_OPTS.
I don’t think this is true, in my system JS scripts had it right all the time, also in this new installation where I have Python Scripting for the first time and then subsequently discovered the discrepancy.
No, joda-js is getting it from org.openhab.core.i18n.TimeZoneProvider.
Here is the code part where Joda ZoneId is initialized.
So in most cases, js is not affected. At least when you use ZonedDateTime in js.
In python it is different. There we use the native datetime which relies on JVM ZoneId.systemDefault()
Means if JVM default datetime is wrong, native python is wrong too.
A workaround for me would to “force/set” the correct ZoneId.systemDefault() if I detect differences to the TimeZoneProvider in my binding. But I don’t like to hide/fix the symptom. This is why I print now a warning (in the unreleased beta) to give the user a hint that something is wrong on his setup.
Well, would already a good step to find out WHERE to change if some conflicting timezones are found.
I did it in /etc/default/openhab, but I am not 100% whether it did it. I undeliberately managed to get the wrong timezone back at a certain point during my trials. But nothing reproducible.
yes, but the TimeZoneProvider is initialized first with the timezone of regional settings from openhab. Only if this setting does not exists, it is falling back to the ZoneId.systemDefault
this means if you provide a regional setting, the result of TimeZoneProvider.getTimeZone can be different then ZoneId.systemDefault
Ideally this should be detected and reported in core. But I have no problems if individual add-ons log warnings and that certainly will be the most expedient way to get this information out for python users.
Traditionally because there is so much complexity the recommended solution is:
a. set the operating system timezone
b. set the -Duser.timezone to the same thing
c. set the regional settings in MainUI → Settings → Regional Settings to the same thing.
With all three pointing to the same timezone all the various timezone problems have gone away in the past.
What can we do to prevent these problems in the future or solve them easier when they occur? But this is probably the solution we should aim for.
Maybe if we understand where it comes back from in my system we can find important insights about the discrepancy in general. I just need help where to search for (wrong) settings. Don’t have a clue.
Timezone setting in WebUI is Europe/Berlin
openhabian ssh shell shows CEST (i.e. Central European Standard Time, correct timezone)
(though this is a question that could be answered).