What if anything should we do to get this back on track?
Any thoughts on why 1 of my Simply Lighting rules worked and 1 didn't?
Rick
Perhaps. I'm also set as US/Eastern and I can confirm that the system knows what time sunrise and sunset are in regards to DST. I don't think there are any places in US/Eastern that don't observe DST. Usually the ones that don't have their own timezone to denote that (like Arizona).
When I set up my hub a couple of weeks ago, even though I had the Timezone and zip set, my latitude and longitude were way off, meaning States off. I have my location stored and updated it. Understand that sunrise/sunset will be different on the east side and west side of your city. Maybe only a couple of minutes but different. I am in Minneapolis which is 400 miles or so from Chicago. Both cities are in the same Timezone. Sunrise for me was 7:34. In Chicago it was 7:08.
Did one of your rules have a time offset (+ or -) and the other did not? Just curious.
It doesn't explain the multiple hours difference some of us are seeing though. My mode change which is supposed to occur at Sunrise+60 didn't fire until one hour late yesterday and 2 hours late today. It also doesn't explain why those of us that do have lat/long set properly had/have issues (mine has been set properly since day one).
Support has already confirmed that there is an issue with DST processing in the hub software.
Most of mine do. I have rules in SL setup at sunrise, sunrise+60 and sunrise+120. I also have mode manager setup with offsets that didn't work correctly on Sunday or today.
I don't have much happen based on sunrise/sunset, but what I did have, fired correctly. It might be helpful for support if people start listing what did and didn't fire to see if there is any pattern to this.
Hi Eric, they both have the same -45 offset. The reason for 2 is, 2 lights get set to 20%, the third gets set to 50%, thus 2 SL Rules
Rick
It's probably too much to paste all the screenshots and log entries - I have them in a Word document if the Hubitat team would like to see them.
I'm at Lat 38.9XXXXX, Long -77.1XXXXX. Sunrise as listed (via Google) - March 10 was 7:26:33 AM, Sunset March 10 was 7:11:01 PM.
I use Mode Manager to set three modes: Day on at Sunrise, Night on at Sunset, and Sleepy Time on at 10:00 PM. These are used to control brightness levels of several lights. According to the logs, these mode changes all happened on schedule (assuming log time stamps were accurate).
I have one Simple Lighting Rule that activates an Outdoor Lighting Scene as Sunset and turns it off at Sunrise. Logs indicate both the on and off events happened on schedule.
I have another Simple Lighting Rule that turns on a spot light on my flag at Sunset with a -30 minute offset and turns it off at Sunrise. On March 9 the logs indicate this light was turned on at 5:40 PM - this appears correct as Sunset was 6:10 PM (30 minutes later). On March 10 the logs indicate this light was turned on at 7:11 PM. That was Sunset on the 10th so it appears the offset was not processed. The light should have come on around 6:41 PM.
That's the summary of what I observed and could mine from the logs.
It looks like for my one rule that has an offset, the offset was ignored. See my message following yours (it took me a while to write it up).
Is there documentation somewhere on what HE is doing with time?
Normally time is always stored as ms since 1970....then displays adjust based on time zone settings.
Similar for inputs, always stored as ms since 1970, and user inputs can show in local or browser timezone, but the system internally has the same value.
Time is easy compared to Time Math.
Meaning: 'sunset' is much easier than sunset + 17 hrs.
This is exactly why computers usually use time a seconds (or ms) since epoch.
Time math becomes simple if all times are just an offset from some known date/time, because time math just becomes integer math.
I strongly doubt that the Hubitat developers came up with a new way of time keeping. I suspect they use the functions of the underlying operating system. Keeping time is pretty easy, it's when bureaucrats add things like Daylight Savings Time AND when you factor in the need to also calculate sunrise and sunset (which has little to do with time zones) for a large number of locations . . . it does still end up being pretty complicated.
Just as a data point, my rule (sunset - 5 minutes, for reference) did indeed work as scheduled today. Anyone else having success, I hope?
Everything worked fine today. My location was also still fine.
Mine worked as well, which is good 
Rick
Well, they have until November to iron out the bugs.
1 Like
its possible it only affects the spring forward change...
Personally I think it is to do with when the rule sets it schedules.
If a sunrise schedule is set the day before a DST change then when the DST change happens the schedule will be one hour out. The next time the schedule is set it will run at the correct time as no DST has happened.
This is only my theory based on no knowledge of how these things work.
What would be interesting is if someone has had the issue but did nothing to try and correct it. Does it all settle down again.
Anyway, that's my tuppence worth for what it's worth based on no knowledges on how those computery thingmebobs work with some bloke called epochy. 
1 Like
