I work in GMT-5 (Georgia, USA) and all but 1 of my backup jobs start at the correct scheduled local time. I have a job scheduled to start every weekday (M-F) at 7:15pm local time. It runs at the correct local time (M-T) but it doesn’t run on Friday since it considers 7:15pm local to actually be 12:15am on Saturday! Saturday it won’t run which is normal then on Sunday at 7:15pm, it will do the backup since it considers it to be 12:15am on Monday…
Am I correct in assuming this is a new issue that suddenly started happening with the daylight saving change?
No, not a new issue… This time change affected my 7:15pm job but I previously had another job starting at 8:30pm which would start at 12:30am or 1:30am depending on if it was DST or EST.
I can confirm that since version 1.3.4 through the current beta 2.0.2.1, that the time start and end is 6 hours ahead of my time, I am in EST. This has been consistent for me on over 50 windows computers. I am not sure where it gets it’s time from, but it is an issue. I am using the Duplicati.CommandLine.exe, I am not sure if this is an issue with the GUI as well.
Here is a log summary as an example when a backup was run at 2PM EST:
SizeOfAddedFiles: 7109392540
SizeOfExaminedFiles: 7109392540
SizeOfOpenedFiles: 7109392540
NotProcessedFiles: 0
AddedFolders: 183
TooLargeFiles: 0
FilesWithError: 0
ModifiedFolders: 0
ModifiedSymlinks: 0
AddedSymlinks: 0
DeletedSymlinks: 0
PartialBackup: False
Dryrun: False
MainOperation: Backup
ParsedResult: Success
VerboseOutput: True
VerboseErrors: False
EndTime: 11/13/2017 8:09:12 PM
BeginTime: 11/13/2017 7:42:30 PM
Duration: 00:26:41.8648338
Messages: [
No remote filesets were deleted
]
Warnings: []
Errors: []Backup completed successfully!
Correction! It is 5 hours ahead of actual time.
Well, I can tell you the general issue behind what you’re seeing but not specifics. Duplicati works with all dates / times internally as GMT and is supposed to convert the internal GMT time to the local time whenever going to actually display dates / times.
Historically, what’s been reported is that a backup is reported as running at the wrong time but on further review it turns out that it’s running at the correct time but in logs and emails it’s recording the wrong time. This, along with the recent daylight saving time change, could be why @supertech360 originally thought things were off by 6 hours then corrected it to 5 hours.
This is the first instance I can think of where a user has reported a job to not run at all due to GMT vs. local time. @kenkendk, are you aware of any issues with the scheduling code where Allowed Days could be using the wrong timezone?
@supertech360, I see that you’re using the beta version but I’m not sure what version @DLR is using. Though I’ll admit I don’t know that any date / time updates have been made to the code since 2.0.2.1 beta.
(BTW - @supertech360, I edited your post by adding “~~~” before and after your text to make your log info more readable.)
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 
), 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…
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.