I think that’s exactly the release path. There was a canary that led to experimental too. Basically test-and-promote. This is my reconstruction of the history. At the moment, canary is beyond both experimental and beta, but that’s what it’s for – you get the latest fixes and the latest bugs. Unfortunately, this issue doesn’t appear fixed even in canary. I can’t speak for development, but would a fix in canary help any of you out? Experimental and beta are not frequent occurrences. Canary can be unpredictable, either stable or not…
Possibly a workaround is to know the bug is there, and adjust the day spec to fit (shift a day to give UTC). That plan gets worse if you backup at a time which is either same UTC day or one-off depending on DST. Original case of 7:15 PM being next day at UTC-5 goes to same-day (23:15) in the DST period at UTC-4. Another problem with workarounds is that the workaround may need removal when actual bug fix arrives.
There are a number of time bugs, and I can’t accurately say which is highest priority. One dangerous one breaks hourly-or-faster backups when times happen twice at DST time change, when clocks are set back. Another perhaps-less-disastrous one is DST causing backups to move around when viewed in local time. Then there’s this bug. At one it was thought changing the scheduler to use local time might fix many bugs (possibly adding others – time is hard), however I wonder if less risky, local, temporary fixes might be had:
DateTime.ToLocalTime Method added to that in the debugger compiler looks promising based on looking at About → System info → proposedSchedule, where the time is in UTC and the formatting is not friendly yet.
If it turns out a simple fix was possible, it’s too bad it didn’t go in. Bug tracking doesn’t seem very formalized, especially from the flood of forum support posts. GitHub issues might do better, but backlogs are abundant.