Exclude files whose names contains would create invalid filters, thanks @kenkendk
What exactly was fixed for: Fixed an issue with invalid DateTimeOffset ?
A job that was set for 18:00 UTC+2 that started running at 17:00 UTC+1 after last Sunday, is now after upgrading set to run at 14:00 UTC+/-???
Should it be sorting out the time zone itself or do we need to reschedule everything so it’s correct going forward?
It fixed this issue: [2.0.4.31] Issue: cannot create a new backup job · Issue #3955 · duplicati/duplicati · GitHub
It’s not related to the daylight saving time change issue.
Ok, so strange that after the upgrade it took another hour off the scheduled time of all the jobs on my machines. I hadn’t touched them after the clocks went back, left them as they were, but have now changed them all to be correct, but I really hope someone picks up this issue for next time.
Really? So your jobs ended up being 2 hours off from what you want?
Regarding the daylight saving issue - I’m not really sure what the plan is.
I think we need to store the start time in the local timezone. All other times are stored in UTC, but for this, the user expects it to happen at some point in the local timezone, so we have to diverge from the “only UTC” rule.
I don’t think that storing it is the issue, it makes sense to be consistent everywhere the date/time is stored, but how you display and execute jobs on that information is where the problem is. For me Duplicati should displaying and executing everything in my time zone, so the calculation needs to be performed before the stored data is used/actioned. If you start diverging in random places of the application, then you’re asking for troubles in the future.
I hope that makes sense.
I have actually seen some products where the scheduling of a task actually has an option like “Use UTC” which is handy for times where jobs are spread globally and you do want them all to start at the exact same time no matter where they are located.
Right now, all times are stored in UTC but always displayed in the local timezone. This makes it nice and consistent. But, the scheduler needs to use the actual local time. I cannot see any way we can make the scheduler timezone aware without storing the timezone with the dates.
That sounds like a nice feature.
But that wasn’t true in my case - the scheduler showed 15:00 one day, then the clocks changed and the next day it showed 14:00 and started executing at that time.
I don’t see any reason to store the timezone anywhere in Duplicati, it just needs to interrogate the operating system to get it when necessary. I’m pretty sure even Microsoft’s own scheduler does this as none of my scheduled tasks have suddenly moved by an hour.
That is how the issue manifests itself. Your clocks change, but UTC does not. The time displayed to you is converted from UTC to local time.
I have not used that scheduler, but if it follows your local clock it does not store times in UTC, but either without a timezone (implicitly using whatever the system has) or with an explicit timezone.
Because Duplicati is running in a browser, it is possible that the browser timezone and the machine timezone are not the same. If we use implicit timezones, we have the problem that the user creating the backup has one timezone but the scheduler has another, so it will not run at the time displayed to the user.
For that reason I think we need to store the expected timezone with the time. We could even allow the user to explicitly set the timezone (maybe just display “Force UTC” as the only option).
I just checked a Task Scheduler job in Windows and this is what the XML holds for a task that executes at 07:30 each day:
<Triggers>
<CalendarTrigger>
<StartBoundary>2019-10-30T07:30:00</StartBoundary>
<ScheduleByDay>
<DaysInterval>1</DaysInterval>
</ScheduleByDay>
</CalendarTrigger>
</Triggers>
No storage of timezone anywhere in the job file, but I enabled the “Synchronize across time zones” option for it and after saving it the same section becomes:
<Triggers>
<CalendarTrigger>
<StartBoundary>2019-10-30T06:30:00Z</StartBoundary>
<Enabled>true</Enabled>
<ScheduleByDay>
<DaysInterval>1</DaysInterval>
</ScheduleByDay>
</CalendarTrigger>
</Triggers>Ok, then it uses an implicit timezone by default.
The Z at the end indicates explicit UTC timezone.