Open rr326 opened 1 month ago
This is a combination of 2 separate problems:
I used to call initialize() when DST transitioned, but I removed that in favor of automatically recalculating the scheduler entries after the transition, but missed updating the docs to reflect this.
The automatic calculation has edge cases that fail and after looking at it for several years I am of the opinion that there is no way to avoid some edge cases. For instance, during DST transitions, some times happen twice, and in other transitions some times never occur. This plus maybe some issues in the implementation make it very difficult to get right, and I can only test each edge case once a year!
So, what I think I will do, is either go back to the calling of initialize() which makes it the app writer’s responsibility and worked flawlessly, or maybe look at automatically re-applying the scheduler calls using the original args as if initialize() had been called, which should have the same effect if it is done after the transition. Either way needs work, but I will look into it.
Awesome that you responded so quickly. Thanks Andrew.
Just re-calling initialize sounds like a good solution to me. Not the most efficient or fast, but it only happens twice a year, and simplicity on your end seems a win!
(I was literally thinking of implementing an app to kill appdaemon upon a transition, so it would be forced to reload.)
What happened?
From the docs, when Daylight savings time changes, it is supposed to re-run initialize(). I have some timers that did not re-initialized and hence the run_daily() were off by an hour. I also found the same issue reported in an appdaemon forum, so it's not just me.
Version
4.4.2
Installation type
Docker container
Relevant log output
Relevant code in the app or config file that caused the issue
Anything else?
This is in appdaemon scheduler.py
Are you sure that elsewhere this actually triggers an intialize() per the docs?