DST change - Schedulation updates by itself

Hello, I’m using the latest build of Duplicati (2.0.6.3_beta_2021-06-17).
With the latest DST change, all the backups are set one hour before.
I have to change it manually to make it works.
Is that a know bug?

DST changes scheduled backup time #1364

Known since 2016?
Not a good start :sweat_smile:

No, but you didn’t click the link to the earlier known issue. Sometimes old bugs are very deeply ingrained.

So deep that I didn’t went so back in time.
BTW it was 2014, 2 years before that I’ve seen.
What can I do for fixing this bug?
Maybe @drwtsn32 could help me? :slightly_smiling_face:

Thanks for the offer. Duplicati only makes progress through volunteer work. Those aren’t keeping up.

Are you a C# developer? That’s the primary need, and the same need applies to all the other Issues.
Not everybody can dig in deep, but there are a lot of easier issues that don’t seem to attract any help.

https://github.com/duplicati/duplicati/blob/master/Duplicati/Server/Scheduler.cs is the scheduler core.
Checking GitHub History finds several fixes that didn’t require a big rewrite. Could this be a limited fix?

Someone would need to go in and learn the design, and apply their knowledge of C# time capabilities.
Having consulting from original developer-volunteer would help, but that person is not readily available.

An example (which may or may not fit the design) of a scheme would be to sanity check the next UTC
run time to see if it makes sense as a local time. If it does not, then adjust UTC. All times exist in UTC.

There is other forum discussion which you can find using search box, or search engine of your choice.
There will probably be more discussion (and I hope users find this thread) in 2 days when US changes.

EDIT:

Actually JavaScript and SQL developers are much needed too, though I’m not certain about this issue…
Anybody who wishes to offer anything (whether code, test, docs, or support) will help improve Duplicati.

I’m not so into C#, but I’ve seen that you’re using DateTime.UtcNow instead of DateTime.Now
I think DateTime.Now is better because “Gets a DateTime object that is set to the current date and time on this computer, expressed as the local time.” as you can see here

Can it be?

Someone (even just recently!) posted a good explanation of some of the programmatical challenges of making such a change: DST changes scheduled backup time · Issue #1364 · duplicati/duplicati · GitHub

While I haven’t looked at any of the code myself, this summary is also assuming that Duplicati has no built in assumptions that the timestamps of all backups are monotonically increasing. For instance, does it even compare the timestamps of two versions to see which is newer or older? What if two have the same exact time? (<=hourly backups when crossing the Fall time change). Again, not saying this is what Duplicati is doing but as mentioned earlier, it depends on how deeply ingrained these timestamps are.

On the plus side, as someone mentions in that github issue thread, countries continue to solve this problem for Duplicati by getting rid of DST. I can’t wait until they do in the US.

1 Like

Since I not live in Greenland, DST changes bother me.
Is there a solution to overcome changes in Duplicati backup time besides manually editing backup schedule twice a year?

From the Duplicati code itself, there is not much to expect given the limited resources. As for myself this is not a problem that is bothering me too much (that is, I think that there are way more important ones).

If you care a lot about it and don’t have the necessary dev skills for fix it, you could script around it by using an external scheduler and launching the backup from this scheduler (that is, the Windows task scheduler if you are using Windows, or anacron or systemd if you are using Linux, or whatever is scheduling tasks in Mac OS if you use that) by either

Thank you, Windows task scheduler is probably the best way to overcome the DST problem with least effort for me. I will try to uses this proposal.