datediff always seems to return "31 days" when using seconds since epoch as input

[Ionic]

This is really, really weird.

$ dateutils.ddiff -i '%s' -f '%Y years, %m months, %d days, %H hours, %M minuts and %S seconds' '1' '1'
0 years, 0 months, 31 days, 0 hours, 0 minutes and 0 seconds
$ dateutils.ddiff -i '%s' -f '%Y years, %m months, %d days, %H hours, %M minuts and %S seconds' '1' '10'
0 years, 0 months, 31 days, 0 hours, 0 minutes and 0 seconds1
$ dateutils.ddiff -i '%s' -f '%Y years, %m months, %d days, %H hours, %M minuts and %S seconds' '1' '1000000'
0 years, 0 months, 31 days, 0 hours, 0 minutes and 0 seconds

Obviously very wrong, but seems to be reproducible whenever using seconds since the Epoch, with any value.

I've also tried giving it dateutils.ddif -i '%s' -f ... "$(dateutils.dconv -f '%s' 'now')" "$(($(dateutils.dconv -f '%s' 'now') + 10))" to see if that makes any difference, but it doesn't.

I've also tried specifying -i '%s' -i '%s' twice to see if it fails to parse one of the UNIX timestamps or parse them in a wrong way when omitted, but this likewise changes nothing.

Am I holding it wrong, or this is a proper bug?

[hroptatyr]

Hey Mihai, thanks for reporting this. It's indeed a bug, good work spoitting it. A fix is in dbfbf3c.

[Ionic]

Great, thank you for the quick fix! I've tried debugging this for hours and ended up in the YMD fixing section, which looked to cause issues, but the root cause was obviously a different one.

[hroptatyr]

Oh sorry for the wasted hours. I admit I didn't think somebody would ever use dateutils on the easy stuff, like two epoch timestamps but there you go.