This should fix the crash that happens if the timesync schedule fires during a DST transition.
The previous behaviour was to get the inverter time then construct a chrono::Local out of it. At certain times, specifically 2022-10-30 01:59 for example, this is ambiguous, because in the UK that time happens twice, once in BST then again in GMT, and chrono raises an exception about it. Note that the inverter doesn't store a timezone.
To try and fix this, we'll always use Utc to create the time object from the inverters time, and pretend it's Utc. Then we make a Utc object for the current time and add on the correct number of seconds to get it to represent the local time (but again, as Utc). Strictly speaking, these are now the wrong time, but they're wrong in equal amounts so are comparable for our purposes.
Hah, thanks for looking at this - my inverter's time became desynced yesterday and I turned on the timesync to fix it. Now I don't have to worry about the end of October :sweat_smile:
This should fix the crash that happens if the timesync schedule fires during a DST transition.
The previous behaviour was to get the inverter time then construct a
chrono::Local
out of it. At certain times, specifically 2022-10-30 01:59 for example, this is ambiguous, because in the UK that time happens twice, once in BST then again in GMT, and chrono raises an exception about it. Note that the inverter doesn't store a timezone.To try and fix this, we'll always use
Utc
to create the time object from the inverters time, and pretend it's Utc. Then we make a Utc object for the current time and add on the correct number of seconds to get it to represent the local time (but again, as Utc). Strictly speaking, these are now the wrong time, but they're wrong in equal amounts so are comparable for our purposes.Fixes #105. Hopefully.