Date Problems on Backup Report

Excellent! Thank you. I will code this into the next version of dR. Appreciate your listening. :slight_smile:

2 Likes

A little slow, but. Well, you were discussing issues with problems with discussing dates, and after 2 re-readings I now understand what you’re saying because of: “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.”

You’re parsing:
EndTime: 11/17/2017 4:46:54 AM
BeginTime: 11/17/2017 4:46:41 AM
…which I think Duplicati will allow the user to customize/and is affected by local settings based on device/os/settings on which Duplicati was run on. I feel sorry for you trying to deal with garbage data input to make a reliable data output.

I was suggesting adding a 2nd sets of dates to the Duplicati log E-mails:
BeginTimeUTC:
EndTimeUTC:
…but you don’t have access to do that as dR :slight_smile:

So I guess my solution is still sound, but you’ll have to get those changes in Duplicati and added to the E-mail report, then you’d be able to utilize that by having an always absolute time value to parse in dR!

1 Like

Agree with that, for multiple format support it would be nice if there would be a second output of the date and time without local formatting. Would be great if it could be added to the report.

I’m using the send-http-url advanced option with my own script and was running into the same issue with some family members getting wrong dates shown on their dashboards (and alert emails).

Maybe a bit related, if not feel free to split the next part! Why is the report only available in plain text? Especially for http post, but probably also for local usage, a json string would be a lot easier to handle. Now I’m breaking the text by characters what works kind of oke but could have some issues with special characters. A gzip json string would be smaller to post and faster to process.

@kenkendk and I went a few rounds on this issue and I think we landed in a pretty good place.

Currently, dupReport 2.0.4 can handle a wide variety of date formats that come in on the EndTime & BeginTime lines (MM/DD/YYY, DD.MM.YYYY, YYYY-MM-DD, etc.). It cheats a little by having the user specify the expected date format in the .rc file on startup. This value is global for all emails, but in the upcoming 2.1 it will be able to be set per backup set, in case you’re receiving backup emails from multiple locales, each with it’s own date formatting. For now, I’m skirting around the timezone/UTC offset problem by ignoring it: whatever time is presented in the email result is reported back out in the dR report.

For 2.1 I’m considering taking the UTC offset info from the incoming email header:

Date: Tue, 24 Oct 2017 15:47:13 -0400

The “-0400” gives an indication of the UTC offset for the incoming email. I can then apply that offset to the EndTime/BeginTime lines and come up with a more accurate representation of the actual date/time of the backup. That’s the theory, anyway. I’d appreciate any feedback you may have on the soundness of this approach.

Finally, @kenkendk indicated that he was adding a timestamp value into the reports:

EndTime: 11/7/2017 12:25 PM (1483273500)

This would allow dR to more easily parse the line and reverse the timestamp into a local date/time value. I endorsed the idea and am able to work with it. If the Council of Smart People deem it better to have separate ‘TimeUTC’ lines in the email, I can work with that also; it just complicates the parsing of the email a bit and adds a little more if/then coding in dR. I’ll leave it up to the CoSP to make a final determination.

As I’m working on dR 2.1 I’m trying to build in more flexibility to handle the insanity of arcane and inconsistent date & time rules and formats. It hasn’t been easy.

1 Like

That would indeed be a great addition! Looking forward to his next release with that included.

If a “standard” for the JSON could be decided on, there’s no reason we couldn’t add an --include-reporting-JSON-in-email parameter.

Or maybe just expose it as a %REPORTING_JSON% variable that could be added to the email body.

Well for email I think using plain text is just fine. That’s what an email eventually is. But for http post it’s a different story since it’s data that’s usually meant to be processed and not just read by an end user.

JSON already has sort of a standardized output, by example:
{"key1":"value1","key2":"value2","keymessages":["message1","messsage2","etc"]}

I’m not familiar with C# unfortunately, but guessing the data is already an array the is probably a json_encode function that could be used.

To be honest I even think the current http-post could be replaced with a well formated way by default. Don’t know if @kenkendk agrees he would probably have to change it. :slight_smile: but would make more sense.

Agreed, I mis-stated what I meant. I was trying to say all parties concerned could agree on the JSON contents up front rather than having an implementation followed by updates.

It is a data structure, but it is fairly simple to dump it as JSON.

Thanks for the reply. If it’s already structured data, could you maybe give me a hint how to use it in an easy way, or how to get a json dump.

If you are looking at the email, the body contents are generated here:

And the generation is done from here:

You should be able to just do NewtonSoft.JsonConvert.SerializeObject(result) instead:

1 Like