ddiff does not care about %s input

[sergiisinelnychenko]

polar@center:/home/polar ddiff --version
datediff 0.4.1
polar@center:/home/polar ddiff -i "%Y-%m-%d %T" -i "%ss" -f "%yy %mm %dd %HH %MM %SS" 12s 15s
0y 0m 0d 0H 0M 0S
polar@center:/home/polar ddiff -i "%Y-%m-%d %T" -i "%ss" -f "%yy %mm %dd %HH %MM %SS" 12s "2018-10-29 14:10:16"
2018y 10m 29d 14H 10M 16S

[hroptatyr]

Hey Sergi, thanks for the report. I can confirm this issue. If you left out the year and month indicator in the first example it would "work":

$ ddiff -i "%Y-%m-%d %T" -i "%ss" -f "%dd %HH %MM %SS" 12s 15s
0d 0H 0M 3S

This is to do with the fact that the %s calendar (duration since some epoch) has no notion of months or years. See info pages 3.3 The refinement rule. Having just read the documentation I have to agree that it's very vague and generally not helpful.

Even less helpful is the output (the 0y 0m 0d 0H 0M 0S result). In my view at least a warning should have been issued. What do you think?

Your up-casting approach (%s gets promoted to ymd, your bottom command line) is one way of dealing with this. Another would be to explicitly convert the input into a calendar that supports all duration format specifiers, e.g.:

$ ddiff -f "%yy %mm %dd %HH %MM %SS" `dconv -i '%ss' -f ymd 12s` `dconv -i '%ss' -f ymd 15s`
0y 0m 0d 0H 0M 3S