Monday at 04:21 PM1 day 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?
Monday at 04:24 PM1 day 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.
Monday at 04:24 PM1 day 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.
Monday at 04:38 PM1 day Author HaHa...I guess I should learn to "accept"!! Edited Monday at 04:38 PM1 day by jkraus
Monday at 04:58 PM1 day 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.
Monday at 05:17 PM1 day 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 Monday at 05:17 PM1 day by GPritchard
Monday at 05:31 PM1 day 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?".
Monday at 05:42 PM1 day 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.
Monday at 06:06 PM1 day 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.
Monday at 07:27 PM1 day 2 hours ago, jkraus said:HaHa...I guess I should learn to "accept"!!Some times it is best not to sweat the small stuff. 🙂
Yesterday at 08:53 AM1 day 14 hours ago, bpwwer said: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.Just turn off DST and and use UTC-x hours. No need to pay any attention to the name of your time zone. Like I am in UTC-6. Personally, I am a fan of DST always.I didn't notice any issues with DST except that programs that run continuously looking for failed heartbeats all reported failed heartbeats at 3am. These programs all track thermometers and look for any change in the temp or humidity which restarts the program. They all have a wait time of 10 or 20 minutes and if no re-trigger of the if clause happens in that time, they send an email. So the jump from 2am to 3am was interpreted as no update in one hour. So I guess a wait clause is not a running timer but rather sets a start time upon starting and then loops back every cycle of a code and does some subtraction. Since 2:05 never happened, and the program triggered at 3am, it must do it that way. I would think that things like waits would run on UTC time and be unaffected by the displayed time, but obviously they use the displayed time. I would expect sunrise and sunset to always run on UTC and your latitude/longitude and therefore be unaffected by chosen display time.If ISY just ran on UTC time everything would work fine through DST switch except something scheduled to happen at displayed time between 2 and 3am.
Create an account or sign in to comment