As mentioned, I think one should hit a local clock that’s network-synchronized.
Network Time Protocol is not an infinite resource. ntpd polls slowly, maybe at
1024 second intervals after stabilizing. App can consult local clock without any
NTP server misuse and abuse. One can also use a local server tracking public.
Companies sometimes do this, and the NTP stratum design allows a hierarchy.
I don’t think Duplicati timestamps files. It backs up the file time – right or wrong.
It doesn’t archive any file one-for-one. Blocks get deduplicated into dblock files.
Metadata such as file timestamp and permissions also get stored as a data block.
FS timestamps on dblock and other archive files don’t matter, but content does.
Archive files are portable. You can sync them or move them. Time doesn’t matter.
The dlist files path name has UTC time of the backup. There’s some checking.
List of backup timestamps contains duplicates” due to DST change
is an example of how local time makes trouble. I don’t know whether others exist.
Your best bet, if not now, then for a possibly more carefully checked future, is the
suggestion I made to run Duplicati on a system (even in VM) using accurate time.
Even if Duplicati tolerates wild times (you can test), user experience will be weird.
Timestamps show up all over the place in the UI, log files, and maybe on network.