search

hroptatyr / dateutils

nifty command line date and time utilities; fast date calculations and conversion in the shell
http://www.fresse.org/dateutils/
Other
613 stars 42 forks source link

ddiff does not care about %s input #89

Open sergiisinelnychenko opened 6 years ago

sergiisinelnychenko commented 6 years ago 
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 commented 6 years ago

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