Why does every time we do a time change The system gets messed up for 24 hours. And then it fixes itself. This has been going on for years and years. Why can’t this issue be addressed?

I'm only guessing, but in another automation controller I've used, some things like sunrise and sunset times are calculated at midnight, when the date rolls over. Any changes would then be seen at the following midnight. It might be something similar.

Don’t know, but I have just come to expect, and accept, it.

It seems about every six months we get a bunch of new topics about daylight savings time. This year less so. I guess many of us have come to accept it.

HaHa...I guess I should learn to "accept"!!

Edited 5 hours ago5 hr by jkraus

Don't think it's related to sunrise/sunset calculations. I have a lights out program that runs at 11:18pm, it didn't run last night because of the time change (as usual), but if it follows the same pattern it will run tonight fine.

Maybe it is ignoring time-of-day and pre-calculating all program start times at midnight so possibly my 11:18pm program would have ran at 12:18, but probably not since that's after midnight. My lights on program did run, but I don't know when since we weren't home, but the lights were on when we got home.

The best solution would be to just get rid of daylight saving time.

Here in British Columbia (Canada), we just performed our very last time change. While some may have preferred we stay permanently on Standard Time (where noon-time has sun at it's zenith), we've now moved to, and will stay on what was formerly known as DST.

So ... maybe programs will gracefully continue, while the world around us is in chaos 🤣

Edited 4 hours ago4 hr by GPritchard

Remember, the time officially changes at 2am, so any sunrise/sunset calculations made at midnight (if this is how the controller works) will be off by an hour that day.

Not trying to excuse this behavior, just pointing out one possibility. I'm also in the camp of "this has been going on for years, why can't the controller take it into account?".

Somewhat off topic ...

While I respect the right for areas to choose to either stay on DST or eliminate DST, I think it's a bad idea to stay on DST.

The ISY software is actually a good example of why. To set the time, you configure the time zone and check if you switch between DST and standard time.

So you (British Columbia) can't just click DST off because your time is no longer the same as what it should be for your timezone. You'll have to switch it off and then set the timezone to some other timezone that has the right standard time to match your non-standard time.

It also seems like this could effect anything that's getting it's time from GPS or maybe even cell towers. Thinks like the navigation in my car seem to know what timezone I'm in and when to switch the time as it did that correctly yesterday and it's only connection is via GPS (no wireless connection and now cell connection).

Changing timezone boundaries to compensate for places that stay on permanent DST seems like it would be a very difficult problem to solve since that's a global, not local change.

But then, maybe all this has already been worked out and won't be a problem.

Some other places like Saskatchewan have been on constant standard time since the 1960's. Adjustments are already being made for zones that are exceptions. It's just a question of making sure any rule changes are kept up to date. But I think that the trend (especially towards constant daylight saving time) will only pick up over the next few years.

2 hours ago, jkraus said:

HaHa...I guess I should learn to "accept"!!

Some times it is best not to sweat the small stuff. 🙂