Incorrect start time

ts678 · December 3, 2018, 7:09pm

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:

github.com

duplicati/duplicati/blob/fd9bec96705b78bcd7b92733d77b433e134fcb93/Duplicati/Server/Scheduler.cs#L380


      
                  /// Returns true if the time is at an allowed weekday, false otherwise

                  /// </summary>

                  /// <param name="time">The time to evaluate</param>

                  /// <param name="allowedDays">The allowed days</param>

                  /// <returns>True if the backup is allowed to run, false otherwise</returns>

                  private static bool IsDateAllowed(DateTime time, DayOfWeek[] allowedDays)

                  {

                      if (allowedDays == null || allowedDays.Length == 0)

                          return true;

                      else

                          return Array.IndexOf<DayOfWeek>(allowedDays, time.DayOfWeek) >= 0; 

                  }

          

              }

          }

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.

mikaelmello · December 4, 2018, 10:33am

I will try to reproduce and see if I can find a fix.

I’m at GMT -2, so I’m guessing if I set up a job to run in some day (let’s say Tuesday) but not in the next (Wednesday) and have it run at 22:15, it should not run, is that correct?

mikaelmello · December 4, 2018, 11:40am

The problem lies on Duplicati using UTC time to check if the backup is allowed to run in a certain weekday, as you previously stated.

The solution I found is to convert it to LocalTime before making the check.

ts678 · December 4, 2018, 12:54pm

Mostly correct, in that it won’t run on the day you requested, but if you look at proposedSchedule it might run 6 days later. Here in UTC-5 time, a Tuesday 12/4 11 PM schedule gets proposed for next Tuesday 12/11 at 4 AM UTC, and in local time that’s Monday 12/10 11 PM. I’m assuming it will run, but I obviously haven’t seen it.

Thanks for the fix! It’s the same one I used, except I just added a ToLocalTime on the line I highlighted. A nice thing about its behavior is that it won’t hurt if the scheduler ever goes to local time, and the code still remains.

DLR · December 4, 2018, 1:24pm

Backups will run at the correct local time, just not on the correct days… It has to do with how Duplicati checks the start time (EST) with its own clock (UTC).

Example: Backup set to run on weekdays at 8pm (EST)

Mon --> Backup starts on Tuesday at 1am (UTC) --> Weekday = run
Tue --> Backup starts on Wed at 1am (UTC) --> Weekday = run
Wed --> Backup starts on Thu at 1am (UTC) --> Weekday = run
Thu --> Backup starts on Fri at 1am (UTC) --> Weekday = run
Fri –> Backup does not start on Sat at 1am (UTC) --> Weekend = don’t run
Sat --> Backup does not start on Sun at 1am (UTC) --> Weekend = don’t run
Sun –> Backup starts on Mon at 1am (UTC) --> Weekday = run

mikaelmello · December 4, 2018, 1:31pm

Exactly, this has to do with the function that checks it the day is allowed. It checks the day on UTC time and not local time. It should be fixed on the next canary if @kenkendk decides to merge my PR.

kenkendk · December 4, 2018, 2:58pm

I have commented on the PR.

The PR will at least make the weekday test use the (server) local day which certainly removes some confusion.

It will not fix the problems with the scheduled run being bound to UTC (meaning it drifts arounds DST changes) as others have reported as an issue.