Duplicati’s JSON HTTP reports have a very unconventional reporting formation for the duration (at least on FR-CA, which is known to be problematic right now).
If a backup lasts over a day, the report’s duration will have an unconventional time format: 1.13:23:59.1679094
Changing the format of this time would be a major compatibility issue, but I believe in a future version, following ISO8601 standard for time durations (although I’ve frankly never seen anyone use this) could be nice. So the above time would become PT37H23M59.1679094S - using days, weeks or months for a duration can result in bugs with daylight savings times or shorter months, so overflowing the hours is fine (and part of the spec).
Otherwise, just having a time where the hour can go over 24 could work, although once again unconventional (such as 37:23:59.1679094) and still a breaking change.
I don’t know why they decided on that format, but at least it is fairly common (by now).
There are no DST issues AFAIK, because the time is measured time, not related to time-of-day or timezones.
I have seen the ISO8601 idea, but honestly, it is a bit convoluted and not easy to read.
That’s good to know! I was wondering where the format came from. Is that consistent across all Duplicati platforms - as in, can I expect the same behavior on Linux for instance?
I parse the reports in an application that keeps track of backups, so consistency would be important.
Yes, this is consistent from .NET across systems. We also rely on the format being stable for our console solution, so I will know very quickly if the format somehow changes.