We completely missed the fact that DateTime variables need to be updated by the platform in certain instances upon the change out of Daylight Savings Time. This omission means that if you live where DST is observed, that your DateTime variables are now probably off by an hour.
We apologize for the problems this no doubt has and will cause. We will endeavor to correct this before March, when DST will again go into effect.
I wondered why my "start morning" was going to start at 4 not 5!
I will give you, you don't seem to hide any thing.
Thanks for such a fantastic, and versatile system.
I'm noticing all my lights came on today at 410pm and yesterday was 610pm ( we use sunset with a slight offset 15m before). Does this mean the issue will correct itself or I need to go and reset the programs and update them for sunset time again (or apply a +1hr offset)?
Is the issue with my program? Where you're getting the sunset/sunrise info? Or some internal calculation of the datetime variable relative to GST?
Please show the app setup that caused this, and also the bottom portion of its App Status page (gear icon) where it shows Scheduled Jobs. Do you have your time zone set correctly in Settings / Localization?
I'm using rule machine, actually still on rule machine legacy. Perhaps this is my problem and I need to migrate my rules over?
Whats interesting is now its showing for tomorrow the scheduled job is the right time (roughly 510pm). Yesterday was 612pm and today was 410pm almost like a double correction for coming off daylight savings time happened one time only.
Here's the log of one of the devices in the rule showing the history:
No, this is not the problem and no you don't need to migrate your rules over.
OK thanks for the feedback. Between the time I noticed the problem, and pulled the screenshots you requested I had already taken the following actions:
1.) updated hub and rebooted
2.) edited rule, and trigger, and saved it (without changing anything)
Not sure if either of these fixed the issue, or if it was just a one time problem for last night with the DST ending.
The way to tell for sure is to look at the Scheduled Jobs on the App Status page for the rule.
Let me suggest that simply changing all times when DST changes is not the proper fix.
DST times are purely cosmetic/convenient. 14:00 EDT is the same as 13:00 EST, and that's the same all year long. The only thing that changes with DST is which enumeration is commonly used. Some may want times to be associated with "wall time", reflecting the change in enumeration. But other rules may want to be run on a straight 24 hour cycle, ignoring DST changes.
Let me suggest that when a time is entered, it be stored as UTC, and the user be allowed a choice as to whether that time should follow DST. Then, at runtime a TZ offset is applied, and for those which want DST adjustment, a DST offset is added (or not, if not DST).
Our scheduler (Quartz) stores time as Epoch time, so effectively UTC. This does avoid all problems with DST (or should). Our issue with variables is a combination of UI and how times are handled when scheduling occurs. There are still some issues buried in that to be sorted.
Download the Hubitat app
