The standard for date format is ISO-8601, which also specifies how to espress durations. For instance, year 0000 doesn't exist which makes your output an invalid ISO-8601date string!
To see what makes dates and durations differ, consider a similar question. I give you two points in 3D space by their coordinates in some base. The 2 points are then well defined and so is the length of the segment joining them. Now I ask you to compute that length expressed in the input format, that is in 3D coordinates and ... you tell Houston you have a problem. Theses formats differ by nature and properties, you can't apply the input format to the output. You have to express the fact that the output is a period, that is prepend 'P' to the output format. See https://en.wikipedia.org/wiki/ISO_8601#Durations
Add to this fundamental problem the variability of a month (is that 28, 29, 30 or 31 days?) and of a year (is that 365 or 366 days?): this output date format looses its meaning and, if using the period format, it looses precision. Periods beyond days, hours and seconds are approximate at best.
The ISO-8601date format is very practical, thanks to its human-readability, un-ambiguousness and self-collating property. It's not even a 6D vector (Y, M, D, h, m, s) since year, month and day are not independant coordinates. But it can't express durations or time periods in the general case unless you use the 'P' format and accept its fuzzy meaning.
Things would be different if your input was in Julian date format: a Julian date is a real >= 0.0 and is in fact a Julian period from the start of the conventional Julian calendar. The difference between two Julian dates is then also a period, hence expressable in Julian date format. See AutoIt _DateToDayValue() and _DayValueToDate() functions albeit they don't handle fractional days (hms are unfortunately ignored).