Incorrect start time

JonMikelV,

I do not use Duplicati’s schedule to start a backup. I use our RMM tool. So the actual run time is not an issue for me & I have not tested it. Yes, the issue I have as I depicted in my log example, is the logged start & end times being 5 hr ahead of my actual time on the applicable computer date/time. So clearly, the log is using GMT time & NOT local time. Thanks.

To be honest I was leaning towards your issue being the “display” problem we’ve seen elsewhere (so thanks for the confirmation :slight_smile:), but I’m not so sure about DLR’s problem.

Running Duplicati - 2.0.1.73_experimental_2017-07-15

My 7:15pm job (M-F) starts at the correct local time and, as everyone else has pointed out, records GMT times in the logs and reports. This could be overlooked as being a bug…

This same job does not run on Friday at 7:15pm since Duplicati thinks that it’s 0:15am on Saturday. Then it will run on Sunday at 7:15pm since Duplicati thinks that it’s 0:15am on Monday. Now I would consider this a major issue…

Dupl1

Dupl2

Dupl3

Agreed, which is why I poked kenkendk earlier as I believe he’s the most familiar with that part of the code.

Oh, and thanks for confirming the version number you’re using.

Let’s keep all related discussion here:

I’ve re-opened because it is a slightly different problem.

I think the problem is that the date is somehow compared in UTC instead of local time. This would explain how you gets the wrong date:

It will probably be fixed once this issue is closed:

Updated to Duplicati - 2.0.2.15_experimental_2018-01-03

The reporting times have been corrected, showing the actual local begin and end times. But the underlying problem of jobs not starting at the correct UTC time is still present.

My Mon-Fri 19:15 and 19:30 jobs will not run on Fridays (Duplicati thinks it’s Saturday) but they will run on Sundays (Duplicati thinks it’s Monday).

Is this issue ever going to be addressed and corrected?

Probably, but other items are higher priority at the moment.

I would think that having backups not run, or run when they’re not supposed to, would be pretty high on the priority list…Especially since this has been an issue for over a year, even before version 2.

I can confirm this is STILL a problem with 2.0.3.3_beta_2018-04-02. This causes major problems for us as our maintenance window is Sunday evenings and the destination server could be offline during this time. Also, because we would like a backup BEFORE there is any maintenence downtime hence the schedule for Friday night. Anyone have any idea when this will be addressed? I can’t believe there are many issues with a higher priority for this long.

Here we are with the latest stable update (2.0.4.2_experimental_2018-11-12) and this time issue STILL has not been solved! Even the beta versions don’t mention that this has been solved… Taking a look at the changelog indicates that the beta versions have the same major changes as does the latest “experimental” version.

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.

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?

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.

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.

1 Like

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

1 Like

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.

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.