DateTimeTrigger and timezones

Good morning, although somewhat earlier as planned.

I am working on some Date/Time based rules to trigger automation around the house. One of which being a sunrise routine in the bedroom.
This is where I noticed that the DateTimeTigger seems to be ignoring the timezone, and treats the time as local.

For example, using the Android app to set the AlarmClock item, which it does in UTC time. After which my rule set a second item a bit earlier.

2022-08-09 23:28:10.261 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'AlarmClock' received command 2022-08-10T06:30:00.000+0000
2022-08-09 23:28:10.272 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'AlarmClock' changed from 2022-08-10T05:00:00.000+0000 to 2022-08-10T06:30:00.000+0000
2022-08-09 23:28:10.312 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Bedroom_VirtualSunrise' received command 2022-08-10T05:55:00.000+0000
2022-08-09 23:28:10.318 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Bedroom_VirtualSunrise' changed from 2022-08-10T04:25:00.000+0000 to 2022-08-10T05:55:00.000+0000

That time is set by the following rule:

rule 'Set Virtual Sunrise time' do
  changed AlarmClock

  run do |event|
    if event.item.state?
      Bedroom_VirtualSunrise << event.item - 35.minutes

To create the virtual sunrise, I’m using the following rule, mostly a copy paste, straight from the documentation:

rule 'Virtual Sunrise' do
  description 'Create a virtual sunrise before the alarm clock sounds'

  trigger 'timer.DateTimeTrigger', itemName:

  run do

However this morning, I had a early rise and shine

2022-08-10 05:55:00.389 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'BlindsBedroomWindow_Vane' received command 50
2022-08-10 05:55:00.391 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'BlindsBedroomWindow_Vane' predicted to become 50
2022-08-10 05:55:00.404 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'BlindsBedroomWindow_Vane' changed from 0 to 50

Note: Timestamps in the logs are local time - Europe/Amsterdam, UTC +2 CEST

I have a different rule to run a Time Of Day routine, which is linked to the astro binding, which seems to set the time in local time, and this one works fine.

The item:

openhab> openhab:status ToD_Day

The rule:

ToD = %w[ Day Afternoon Evening ]

ToD.each do |t|
  rule "Set Time of Day to #{t}" do
    trigger 'timer.DateTimeTrigger', itemName: 'ToD_' + t
    run { items['TimeOfDay'].command(t) }

The logs:

2022-08-10 06:21:00.729 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'TimeOfDay' received command Day
2022-08-10 06:21:00.732 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TimeOfDay' changed from Evening to Day

As both the sunrise and the timeofday items clearly include a timezone/offset, I would expect that any triggers would compensate for this.

I’m not sure if this is a JRuby issue, a upstream issue at the DateTimeTrigger implementation, or a issue that sites between my keyboard and chair :slight_smile:

That’s good, that tells us your Java timezone is set correctly, which is the usual cause of time-shift issues.

I wouldn’t be surprised, it is a new feature.

It’s perfectly acceptable to set a DateTime Item to UTC or any other zone. It just represents some moment in time.

It does appear that the time-trigger setup is making a mess of it, extracting 05:50 from the Item, ignoring the UTC zone, and wrongly scheduling the trigger for 05:50 local time.

Ok, so that might be worth investigating then, and sure enough…

Test setup in Rule DSL

rule "DateTimeTrigger timezones"
    Time is MyTestDateTime
    logInfo("DateTimeTrigger", "The test DateTime item caused a trigger!")

Setting a timestamp with UTC timezone

openhab> openhab:send MyTestDateTime 2022-08-10T11:29:00.000+0000
Command has been sent successfully.

Log output

2022-08-10 11:28:26.844 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'MyTestDateTime' received command 2022-08-10T11:29:00.000+0000
2022-08-10 11:28:26.855 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MyTestDateTime' changed from NULL to 2022-08-10T11:29:00.000+0000
2022-08-10 11:29:00.939 [INFO ] [ab.core.model.script.DateTimeTrigger] - The test DateTime item caused a trigger!

Now let’s retry with a CEST timezone.

Setting a timestamp with CEST timezone

openhab> openhab:send MyTestDateTime 2022-08-10T11:33:00.000+0200
Command has been sent successfully.

Log output

2022-08-10 11:32:31.064 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'MyTestDateTime' received command 2022-08-10T11:33:00.000+0200
2022-08-10 11:32:31.096 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'MyTestDateTime' changed from 2022-08-10T11:29:00.000+0000 to 2022-08-10T11:33:00.000+0200
2022-08-10 11:33:00.117 [INFO ] [ab.core.model.script.DateTimeTrigger] - The test DateTime item caused a trigger!

Looks like I am heading on out to upstream and opening a issue on Github :slight_smile:

Upstream bug report: DateTimeTrigger not taking timezones into account · Issue #3059 · openhab/openhab-core · GitHub


I posted a PR to fix this. A workaround would be to convert the zone in your rule

rule 'Set Virtual Sunrise time' do
  changed AlarmClock

  run do |event|
    if event.item.state?
      Bedroom_VirtualSunrise << (event.item - 35.minutes).with_zone_same_instant(ZoneId.system_default)

I am afraid I cannot test the jar of the PR as I am on openHAB 3.3.0. But I am able to confirm your workaround works!

2022-08-10 14:10:16.506 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'AlarmClock' received command 2022-08-11T05:00:00.000+0000
2022-08-10 14:10:16.514 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'AlarmClock' changed from UNDEF to 2022-08-11T05:00:00.000+0000
2022-08-10 14:10:16.625 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Bedroom_VirtualSunrise' received command 2022-08-11T06:25:00.000+0200
2022-08-10 14:10:16.652 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Bedroom_VirtualSunrise' changed from NULL to 2022-08-11T06:25:00.000+0200


I’ve uploaded a jar for 3.3 too.

Just wanted to chime in that I’m experiencing the same problem with the AlarmClock item updating with UTC time values after switching to the openhabian “main” branch (claims to be the latest release). The jar files mentioned above are no longer available, either. Should I just use a rule to change the time until the fix is moved into the main branch?

I don’t know what you mean by “openhabian main branch”. The fix is included in the latest 3.4 milestone

I still don’t understand what the “main branch” means here. The fix is already merged into the git main branch and included in the 3.4.0.M3 milestone version (probably also M2 but that’s not the latest milestone anyway). Did you mean “main branch” as in the stable version 3.3.0?

In any case, yes do use a rule if not using a rule means it doesn’t work as expected. It should be fixed in 3.4.0 (stable, not yet released as of writing)

Thank you for the feedback, Jim. The naming is very confusing, for me at least, because Openhabian seems to follow a slightly different nomenclature (or perhaps the same but with different intent); it’s not the first time someone has said they don’t know what I mean by this. Please see the attached screenshot from the openhabian-config utility.

That screenshot refers to the openhabian branch in github - not the openhab/OH branch !
In the headline you can see openhabian version.
Both branches ( openhabian vs. OH ) are more or less independent of each other.

Further down in the openhabian-config menu structure you also can find a menu entry to switch between OH branches ( like stable/testing/unstable )

The wording in that screenshot is confusing and misleading. Very ambiguous. No wonder people misunderstood!

I have never touched openhabian, but I’d suggest for the maintainer to rewrite the wording there. @mstormi ?


I’m open to any suggestion but I wouldn’t think so. The problem is that both of you misunderstood because you applied the wrong context here.
People often do not read carefully enough and don’t make the needed proper distinction of what is openHAB and what is openHABian.
That now isn’t anything I can solve from within …

Why not make it so that there’s no room for misinterpretation? Clearly the current wording is causing one at least for some people.

Because that’s impossible. There always is room when the reader applies a wrong context.
As I said I’m open to suggestions so what’s yours ?

Do you want me to rewrite that screen?
I don’t use openhabian but if you are actually open to changing it, I can give it a go.

sure, any contribution is welcome