I have a situation, where the clock on a pc, has to be changed. This also includes situations where clock was changed accidentally into the future, or there is some hardware problem with the clock.
My proposition: simple NTP library → get the clock from the network, from at least 2-3 NTP servers, instead of a local time. Only for the chosen backup. A new option in advanced options for the backup → “Get time from network for this backup”
Also a logic, chosable by the user, when there is no network available: fallback to the local clock, or stop the backup.
I’m not a Windows guy (guessing from @cowboy’s other post he is) but the only programs I can think of that don’t trust the local clock are daemons that keep the local clock in sync.
I’ve dealt with some systems that have had to do weird things with the clock (e.g., a performance test system that needed to relive the same day in history over and over to mesh with the data that was used for testing. The logic gets tricky quickly because sometimes you want system time and sometimes you want world time. E.g., you’re running a backup and a file has changed its hash. It’s currently a later world time that the last time the file was stored, but in system time this file now has a timestamp that’s earlier than the last time the file was stored. Which version might need to be restored later, the more recent world time, or the more recent system time? Both could be valid depending on the situation.
Also, Duplicati would have to continuously run its own NTP daemon to do anything more than simple, one-shot time query against a single outside source. You can’t just average multiple sources together, you have to do all the jitter, network latency, and outlier math that an NTP daemon does, which needs at least 10 minutes and ideally hours of accrued tracking data to do with confidence.
If you need something that you can’t schedule with Duplicati’s scheduled jobs, maybe you could schedule a cli job using the system scheduler?