Here’s one I haven’t see before. I had a backup that was run today (10/26/17) but the report says it was run tomorrow:
I’ve checked my system time and locale settings - both are accurate. Been running Duplicati for a couple of months now and haven’t seen this. Any idea what the cause might be?
I believe Duplicati internally users GMT times, so depending on your local timezone the internal date could have been “tomorrow”.
There are a few known (reported on this forum) instances of the GUI apparently not converting to local date-time for some reason, but since it’s a “presentation only” issue I don’t know that any work has been done to resolve it yet.
The weird thing, however, is that the GUI wasn’t involved here. The backup was run as a service on a Windows machine and the result email sent from the service to Gmail. The wrong date was embedded in the email. I’m not that familiar with Duplicati internals, so would the GUI problems you mention pertain to the service component as well?
Sorry - I could have been more clear. I believe the GUI is really just a pretty front end for the command-line, which to a large extent is a front end for the server (whether it’s service or TrayIcon based).
When I said “GUI” I should have said “any part of the code that spits out a date/time for external use”.
So, yes - I think it’s the same issue.
Just for completeness, can you confirm what version you’re running? It’s possible somebody has fixed this in a newer canary version…
Thanks for the clarification. I’m running 2.0.2.1_beta_2017-08-01
I’ve done some more checking, and it seems that all the systems I’m running Duplicati on are consistently reporting the time to be later than “actual” time. Most are reporting a 5 hour difference but one is off by 7 hours. I checked the time and locale settings on all the systems and they are accurate (UTC -6), but for some reason Duplicati is adjusting the time.
The good news is that the program is running just fine, it’s just that the reporting dates are off. The only reason I actually noticed is that it’s throwing the dupReport reports off a bit. Not a world crisis, to be sure, just odd.
Thanks.
The intention is that all internal date/time is kept in UTC, and often serialized to “ticks” or “EPOCH” format.
The output here is a case where the time is reported in UTC, but should be in “user time”.
Since you are parsing the timestamp, I suppose we have two conflicting ways of handling this. The user expects the times to be displayed in their native format (i.e. what the locale says it should look like), but dupReport wants something that is “parseable”.
Do you have a good solution for this?
I don’t suppose using (or at least exposing) Julian dates would be at all useful…
No, because that is not native.
There are some formats here:
The “G” is what I would use as the “what the user expects”, and parse-able would be “u”, or the format that I use in some instances: yyyyMMdd'T'HHmmssK, where T is a literal ‘T’ and K is the timezone offset specifier. (It is essentially the O specifier without milliseconds.)
Sorry, I edited my original reply after re-reading the thread. Could the solution be as simple as a setting that tells Duplicati what locale to use in reports? That way, D. can use UTC or Epoch settings all it wants, and use the local settings only when interfacing with the outside world, i.e. when producing reports.
The web interface seems to be locale-sensitive when it displays when backup jobs are scheduled or run. Is that a separate process from the reporting engine?
Yeah, there is one already: --force-locale=en-US.
Yes, that is what I want it to do. But I see that this will make it seriously difficult for something like dupReport to parse the date?
Yes, actually the dates are also reported in UTC, but the UI converts them. This does not happen in the report area, because this is text box and not individual elements.
I tried --force-locale=en-US. It still reports the time as UTC. The location is correct but the time zone (UTC -6) isn’t getting picked up, so the date/time in the report is still getting reported as UTC.
As for the difficulty of dR parsing dates, that may be true. Since I only have one TZ to test in I’m sure there are more than a couple locale-dependent issues I’ll have to deal with eventually. If we can get Duplicati to a consistent and logical format, I can code around it.
You probably already know this but just in case, don’t forget some TZ will have a Daylight Savings Time shift this coming Sunday (Nov. 5) morning. I’d hate for that to skew your testing. 
I was being unclear, the locale affects the output format, not the timezone. I can easily change the timezone to the local time:
But this uses whatever locale the user has chosen. I guess this is not different from how it is now.
Maybe a second version could be to add the unix-time timestamp, so it would look like:
Started: Jan 1, 2017 12:25pm (1483273500)
That should make it fairly simple to extract the number and use EPOCH.AddSeconds(1483273500) to get the time it represents.
So would adding two more date fields solve both issues?
A UTC start/end for dupreport and locale time for ease of users reading reports?
I just spent the weekend rewriting dupReport’s date recognition code because, evidently, you can use a dot (.) as a date separator. Who knew??? (
) Anyway, dR can now recognize all permutations of DD/MM/YYYY with various separator options [/-.]. What would become difficult is parsing a native-language date spec (e.g., “January 1, 2017 12:25pm”) because of, well, different languages. Remember, dR has only the job status email text to go by for all its work. dR has no access to the Duplicati server or database from which to glean any additional intelligence about the backup job or the locale. In addition, the locale/TZ where dR is run may be different than the locale/TZ where the Duplicati backup job was run, adding just a bit more complication to the issue.
dR’s needs are simple: start & stop dates & times (preferably in some variation of the XX/XX/XX format) with some indication of the UTC offset in the timezone where the program was run included in the email. kenkendk has indicated that might be/is already in the code, but I’m assuming that’s in the canary builds and I’m working off the released beta code. Alternately, if Duplicati wants to include a pure UTC date/time in the report email (either as the default or as an additional field) that would be fine as well. I can work with either of those options.
I don’t think you can do that, because the US has MM/DD/YYYY where other countries use DD/MM/YYYY. Given 03/04/2017 there is no way to figure out which is which.
If you can work with the unix timestamp in parenthesis after the local date, then I suggest we use that one. It is also easy to detect if the timestamp is there: simply look for a trailing ).
@silversword411 Do you need to parse the date as well, or is it in order to use dupReport better?
I’m cheating around that problem in my upcoming version by having a config option to identify the date format. Available formts are:
Given the format spec I can parse the incoming string and return an actual date. Let me look into the unix timestamp a bit and confirm I can get that to work.
Yeah…sorry about that. That’s been around since all those guys signed that pesky declaration paper a little while ago. 
OK, I’m more awake now 
. Using a ‘(timestamp)’ notation after a local date will work for dR. You’re right, just regex-ing for ‘(<blob>)’ will do the trick. I would also suggest keeping the current ‘XX/XX/XX HH:MM:SS xM’ notation as well. The full line in the email would be:
EndTime: 11/7/2017 12:25 PM (1483273500)
Or, for the rest of the world:
EndTime: 7/11/2017 12:25 PM (1483273500)
Again, dR can properly recognize either form. That would allow parsing on either the verbal date or the timestamp spec, or both. One thing I’ve found working with datetime over the past few weeks is that more cues are better, especially when trying to compare dates. Having both will also allow me to deduce the TZ offset, for cases where I’m pulling in emails from multiple time zones.
Yes, that is the idea. I have implemented it, and will merge it into master asap.