Return to Answer

To some extent, even a duration in seconds is ambiguous. For simplification, the seconds in the Unix epoch time are defined as the 86400th part of a given Earth day. Those seconds are getting longer and longer as Earth spins down.

(that may still be a good enough approximation for you).

To some extent, even a duration in seconds is ambiguous. For simplification, the seconds in the Unix epoch time are defined as the 86400th part of a given Earth day¹. Those seconds are getting longer and longer as Earth spins down.

(that may still be a good enough approximation for you).

_{¹ Technically, while a day is 86400 Unix seconds long, network-connected systems typically synchronise their clock to atomic clocks using SI seconds. When an atomic clock says 12:00:00.00, those Unix systems also say 12:00:00.00. The exception is only upon the introduction of leap seconds, where either there's one Unix second that lasts 2 seconds or a few seconds that last a bit longer to smear that extra second upon a longer period.}

_{So, it is possible to know the exact duration (in terms of atomic seconds) in between two Unix time stamps (issued by systems synchronised to atomic clock): get the difference of Unix epoch time between the two timestamps and add the number of leap seconds that have been added in between.}

_{datediff also has a -f %rS to get the number of real seconds in between two dates:}

$ dateutils.ddiff -f %S '1990-01-01 00:00:00' '2010-01-01 00:00:00' 631152000 $ dateutils.ddiff -f %rS '1990-01-01 00:00:00' '2010-01-01 00:00:00' 631152009

_{The difference is for the 9 leap seconds that have been added in between 1990 and 2010.}

_{Now, that number of real seconds is not going to help you to calculate the number of days as days don't have a constant number of real seconds. There are exactly 20 years between those 2 dates and those 9 leaps seconds rather get in the way to get to that value. Also note that ddiff's %rS only works when not combined with other format specifiers. Also, future leap seconds are not known long in advance, but also information about recent leap seconds may not be available. For instance, my system doesn't know about the ones after 2012-07-01.}

Would generally not give you something that is correct as the time delta is applied to 1970 instead of the actual start date 2016.

Or in fish:

date -d@(expr (date -d $d2 +%s) - (date -d $d1 +%s)) +'%Y %-m %-d %T' | \ awk '{printf "%s years, %s months, %s days, %s\n", $1-1970, $2-1, $3-1, $4, $5}' 

Would generally not give you something that is correct as the time delta is applied to 1970 instead of the actual start date 2016.

(dates taken as UTC, add something like --from-zone=Europe/London for the dates to be taken as local time in the corresponding time zone).

(dates taken as UTC, add something like --from-zone=Europe/London for the dates to be taken as local time in the corresponding time zone. --from-zone=localtime may work for the default timezone in the system; --from-zone="${TZ#:}" would work as long as $TZ specifies the path of a IANA timezone file (like TZ=:Europe/London, not TZ=GMT0BST,M3.5.0/1:00:00,M10.5.0/2:00:00 POSIX-style TZ specification)).