'today hh:mm' produces error "cannot make sense of"

[LightningStalker]

Hello again. I'm not sure if weather this is a bug or a feature, or maybe I'm just doing it wrong, but specifying a time of today produces the following output from ddiff.

ddiff: cannot make sense of `today ??:??' using the given input formats

Here is the actual command line I'm using.

$ ddiff --from-zone $TZ -f '%H:%M:%S' now 'today 17:39'

Specifying today's date as 2014-09-14 does work. It appears to be something with the 'today' functionality itself.

I recompiled from the latest git to see if it was something in the older version I was using, but 0.3.0.git39.79657eb is producing the same result.

Thanks.

[hroptatyr]

Hey, thanks for the report.

Yes, the syntax you describe is not supported. The today, now, yesterday, tomorrow short cuts are absolute and cannot be ``refined''. As a quick workaround you could:

$ ddiff --from-zone "${TZ}" -f '%H:%M:%S' now `dconv today`T17:39
12:34:36

i.e. do inplace command calls, which I think are more flexible than supporting refinement syntax, at the price of another process running. But this way you can also specify things that are 2 or more days from today (day before yesterday, day after tomorrow, etc.) the same way.

And it's consistent with stdin syntax (where I'd hate to support 'today 17:39' or similar because that makes the parsing really slow), i.e.

$ dseq -f '%F 17:39' 2014-09-13 today | ddiff now -f '%H:%M:%S'
-35:-30:-36
-11:-30:-36
12:29:24

Apart from the ugly triple minus signs in there, which is clearly a bug.

[hroptatyr]

Just to be clear, I didn't want to brush you or the feature request off; I'm just worried about the overall consistency of the tools, and changes like this are somewhat difficult to justify (be it to myself or other users), for instance if 'today 17:39' is supported then '2014-09-15 time' should be as well, turning today and time effectively into magic shortcuts, a few versions down the road and we have '2014-09-15 noon' or '2014-09-15 tea time' or 'month's first 17:39' (like the original Unix at(1) command).

Personally I find them (a) hard to remember and (b) their magic (to substitute for values) is completely identical to process substitution as I described above. So I'd definitely need more convincing were I to implement them (use cases, actual command lines that are now 10 times easier to produce/read, etc.).

So feel free to convince me :)

[LightningStalker]

I understand where you're coming from. The above does look like a good solution for this situation.

Thanks.