I have a rule that is triggered by a dateTime variable. I created the hub variable last month and have not changed the time in a few weeks. Here is a screenshot of the variable connector device page:
This morning the rule triggered at 6am, not 7am. Seemingly a DST issue, but I’m not sure if it’s an issue with the variable, the rule, or something else. Screenshots from the rule’s app status page are below:
I suppose it depends on when you set the variable.
If you set it before DST changed the time then it would have the pre-DST time in it I suppose.
It should be OK from now on if this is the case. (Until the next DST change).
When did you set the variable?
DST is a nightmare and I know the HE team seem to tweak bits and pieces around it reguarly.
Since I set the variable to 7am EDT (i.e. prior to the end of DST), I would expect that when DST ends, the hub should automatically update the variable time to 7am EST. Perhaps I am misunderstanding how the hub handles this, but IMHO it wouldn’t make any sense to keep the “original” time after DST ends. After all, everything else with a clock has moved back one hour (except for where DST isn’t in effect, of course, but it is where I live, and the hub otherwise “knew” what time it was after DST ended at 2am local time).
I agree, and I certainly wouldn’t complain if the entire concept was scrapped entirely. But @dman2306 said it well in another thread this morning:
What matters is where it is used in a scheduled job. You didn't show that. The hub used the then in effect timezone offset (-0400) when you set the variable. There is no logic in the hub to update dateTime variables on DST change -- perhaps their should be, but there isn't. Scheduled jobs are updated to reflect the change in the timezone offset. So you got caught in between those two.
Sorry but where would that show up if not in the app events page? (I’m using an iPad at the moment while traveling, not a desktop browser, so it’s possible I inadvertently did not include part of the app events page when uploading the screenshots)
Ah I see, the predicate condition is currently false since the hub isn’t in one of the defined modes (although it was this morning).
I may not be accounting for all use cases, but it seems like it would make sense for the default behavior of dateTime variables to update one hour forward/back when DST starts/ends.
I really do need to see the Scheduled Job for that. There is more than one thing going on, one has to do with the UI, and the other with the Scheduled Job. The UI one I understand and can fix.
That's strange, because it should have had a schedule of 0 0 7 * * ? before, and that would not have been messed up by DST change. Hitting Done would mess it up, because the connector time is 6:00 AM after the DST change.
It’s possible I hit done earlier today while trying to look into what was going on (i.e. before my last screenshot), although I don’t specifically recall doing so. In case that matters.
Just a few mins ago I tried to update the variable connector time to 7am. Not sure what I’ve done now, but the hub variables page now throws an error instead of loading. And it appears to be related to this log entry:
