The timezone of the OS is Etc/UTC, the timezone of openHAB is Europe/Berlin as set in /etc/openhab2/services/runtime.cfg.
The results are mixed:
local times for sunrise, sunset from the astro-Binding are correct.
Timezone display in the Paper-UI / Configuration / System / Regional Settings is correct, however showing 1 hour offset, while 2 hours is the correct value during daylight saving time.
The times used for DSL-rules and scripted automation / jython are UTC:
log.info("datetime.time(): {}".format(datetime.time()))
log.info("datetime.datetime.now(): {}".format(datetime.datetime.now()))
log.info("The ZonedDateTime is: {}".format(format_date(ZonedDateTime.now())))
log.info("The LocalDateTime is: {}".format(format_date(LocalDateTime.now())))
log.info("The ZoneId.systemDefault() is: {}".format(ZoneId.systemDefault()))
log.info("The DateTime is: {}".format(DateTime.now().toString()))
How can the org.eclipse.smarthome.i18n settings be accessed by an automation module?
If the org.eclipse.smarthome.i18n settings are not used through all bundles in openHAB, what is their intention?
Can you confirm, that the best way to set the timezone is to do so on the level of the operating system instead of org.eclipse.smarthome.i18n?
@rossko57:
Good Point, I added the appropriate option to EXTRA_JAVA_OPTS in /etc/default/openhab2 and the code snippets from my first post all show the correct local time / locale.
Before, I had the underlying OS configured in local time, so I did not run into these issues before. Not long ago I moved my home’s openHAB to this VM and just would like to know if it is really necessary to do locale configuration in 3 places
operating system
/etc/default/openhab2
/etc/openhab2/services/runtime.cfg or Paper-UI respectively
and what these settings have an impact on.
The starting point was, that option 3 is not sufficient for DSL-rules and automation being provided with the correct locale / timezone.
After reading @rossko57’s Post I changed option 2 and can confirm, that options 2 and 3 together are working (except the faulty time offset in the display).
It could be, if you wrote every rule very carefully to reference OH timezone rather than java’s version of “now”. Probably impractical. DSL Rules are essentially java and so take their cue from the java engine’s ideas.