Daylight Savings Issues

This thread has gone silent, have the DST bugs ever been repaired?
 
It seems the firmware download page is still on 5.3.10 from 2016.
 
I'm having time issues and figured I'd start with the latest firmware.
 
I'm using M1XEP with NTP, daylight savings time enabled and proper dates, proper +8 timezone offset for Pacific time and the displayed time is 3 hours behind the correct time.
 
kwschumm said:
This thread has gone silent, have the DST bugs ever been repaired?
 
It seems the firmware download page is still on 5.3.10 from 2016.
 
I'm having time issues and figured I'd start with the latest firmware.
 
I'm using M1XEP with NTP, daylight savings time enabled and proper dates, proper +8 timezone offset for Pacific time and the displayed time is 3 hours behind the correct time.
There is no fix that works for all cases. Petition your government to dump DST.
 
Each program has to know the intent of the code writer.
 
What do you want your HA to do when there are two 2:30 AMs?
What do you want your HA to do when there is no 2:30 AM?
 
LarrylLix said:
There is no fix that works for all cases. Petition your government to dump DST.
 
Each program has to know the intent of the code writer.
 
What do you want your HA to do when there are two 2:30 AMs?
What do you want your HA to do when there is no 2:30 AM?
I just want it to tell the time accurately. The rest is a rule issue. Worst case don't use time specific rules between midnight and 4:00. Easy enough.
 
kwschumm said:
I just want it to tell the time accurately. The rest is a rule issue. Worst case don't use time specific rules between midnight and 4:00. Easy enough.
That would mean never using a repeat every x minutes/hours. Wouldn't be much of a HA system without any cycling provisions.
 
Time is usually updated from the cloud X times per day but you didn't mention a particular system.
Oooops. I didn't see the Elk title at the top. I don't have one.
 
The best way to implement timers is to make all timers relative. Keep a sorted queue of timers, in seconds until expiration, with the first to expire at the head of the queue. Decrement the timers by one each second. When the timer at the head of the queue reaches zero execute the action, reschedule the timer if needed and reinsert it in the sorted queue. Easy. When the clock jumps forward/back an hour add/subtract 3600 seconds to each timer in the list and execute the timer action right away if the timer goes negative when subtracting. Not perfect, nothing is when clocks move backwards, but it's about the best you can do and it's not difficult.
 
That only works for some cases. This has been hashed to death in other forums. There is no universal technique to solve it except to petition the powers that be.

Sent using Tapatalk
 
I have used this exact technique in several 24x7 embedded systems I have written and never had a complaint. It's not perfect but is a lot better than Elk has now.
 
Regardless, I guess it's useless to ask Elk to IMPROVE IT AND DOCUMENT THE BEHAVIOR since they've no interest in doing so.
 
Looks like M1 development is dead in the water.
 
kwschumm said:
This thread has gone silent, have the DST bugs ever been repaired?
 
It seems the firmware download page is still on 5.3.10 from 2016.
 
I'm having time issues and figured I'd start with the latest firmware.
 
I'm using M1XEP with NTP, daylight savings time enabled and proper dates, proper +8 timezone offset for Pacific time and the displayed time is 3 hours behind the correct time.
That's odd.  I have the exact same system, am on the Pacific coast and my M1 keeps perfect time.
 
keepersg said:
That's odd.  I have the exact same system, am on the Pacific coast and my M1 keeps perfect time.
The time is fixed, which was really all I needed. After setting for three days with the wrong time I went to the XEP and forced it to update the time, at which point the time was corrected.
 
Back
Top