Way back in the depths of time this general use case is why I created the Time of Day design pattern. Design Pattern: Simple State Machine (e.g. Time Of Day)
Over all what you do is separate the calculation on when to do this from what to do. You’d have one rule or rules which keep track of the time and update/command an item (e.g. at sunrise command an Item with DAY). Changes to that stare Item can be used to trigger rules, used in if statements in rules, etc.
To handle restarts and such, the rule or rules that calculate the time of day usually have an “at midnight” trigger and a “restart” trigger to calculate the current state and set the timers for future states at the start of a new day and on OH restart.
So, for example, if OH is down when the charging time has passed, when OH comes back up it runs, sees it’s currently between the charging start and stop times and commands/updates the state Item. The state Item changed to CHARGE (or some such) triggering the rule that starts the charging, even though OH missed the exact start time.
Time Based State Machine [4.0.0.0;5.9.9.9] provides a relatively complete time if day tracking which might be more than you need for this.