Support date predicates in advanced expr: queries

[rickswe]

Hello, I recently came across a limitation in hledger while trying to build a more advanced expr: query involving dates.

For reference, Ledger supports date expressions in value expressions, including comparisons such as date < [tomorrow] and date >= [tomorrow]: Ledger CLI — Date Expressions

I'd like expr: queries to support date predicates as part of more advanced boolean expressions.

For example:

hledger is -p "2023 to 2028" --forecast='tomorrow..2028' -Y -3 -S \
    expr:'(date:<tomorrow AND NOT tag:future) OR (date:>=tomorrow AND tag:future)'

The intended result is:

• Before tomorrow: include transactions not tagged future.
• Tomorrow onward: include only transactions tagged future.

I understand this particular forecasting example can be worked around by adjusting the periodic/budget entries and controlling the forecast period. However, I still think being able to apply different query conditions to different date ranges in a single expression would be useful more generally.

Ideally, date predicates such as these could be combined normally with AND, OR, NOT, and parentheses:

date:<today
date:<=today
date:>=tomorrow
date:>2027-01-01

Related: #2177 and #2178 cover the date/OR behavior that led to the current restriction, while #2095 discusses making expr: queries more expressive in general.

Thank you for all the work on hledger.

[simonmichael]

Hi - we do support date predicates, but not the < > = syntax. So instead of

expr:'(date:<tomorrow AND NOT tag:future) OR (date:>=tomorrow AND tag:future)'

we'd write that as

expr:'(date:..tomorrow AND NOT tag:future) OR (date:tomorrow.. AND tag:future)'

- can also be used, instead of ..:

expr:'(date:-tomorrow AND NOT tag:future) OR (date:tomorrow- AND tag:future)'

We do support < > = when querying amounts, and I agree supporting them for dates would be nice. At the command line they are harder to type (you have to put them in quotes to protect from the shell), but they're intuitive.

[simonmichael]

(If it's not clear, https://hledger.org/1.52/hledger.html#date-query takes a period expression, and this is the STARTDATE-ENDDATE or STARTDATE..ENDDATE syntax for a period expression, with one of the ends omitted.)

[simonmichael]

PPS I say adding < > = syntax for date queries would be nice to have, but that needs to be pinned down. date: takes a PERIODEXPR, so the simplest thing would probably be to accept <DATE, <=DATE, =DATE, >=DATE, >DATE as another syntax for https://hledger.org/1.52/hledger.html#period-expressions. With these equivalences:

	equivalent to:
<DATE	..DATE
<=DATE	..DATE+1
=DATE	DATE
>=DATE	DATE..
>DATE	DATE+1..

[simonmichael]

Any downsides ?

Period expressions are used elsewhere, eg the -p option, periodic transaction rules, filter expressions in hledger-ui and hledger-web. This shouldn't be a problem for those.

The new syntax will require quoting at the command line. People who try to write hledger print date:>today without quotes will get a surprising result, and will have to learn to write something else (hledger print 'date:>today', hledger print date:tomorrow.., hledger print -b tomorrow etc).

More ways of spelling a thing adds uncertainty and confusion, generally.
Eg instead of date:jan..jul, people may try writing date:'>=jan && <jul', which won't work.

[simonmichael]

Supporting date:'>DATE' might encourage users to try date:'>DATE1 && <DATE2' (expecting date: itself to handle boolean expressions). So we'd have to explain that it doesn't, such logic needs to be done outside the date: term.

[rickswe]

@simonmichael Thanks, that clarifies the date syntax. I'm using 1.52 version by the way.

Using .. instead of < / >= makes sense to avoid the quotes.

However, the suggested expression still fails because date: cannot currently be used inside an OR expression:

hledger is -p "2023 to 2028" --forecast='tomorrow..2028' -Y -3 -S \
  expr:'(date:..tomorrow AND NOT tag:future) OR (date:tomorrow.. AND tag:future)'

This gives:

hledger: Error: failed to parse query:
sorry, using date: in OR expressions is not supported.

So it looks like there are two separate issues here:

1. Date comparisons should use period syntax like ...
2. Even with valid date syntax, this particular query is still blocked by the current date: + OR limitation.

[simonmichael]

1 already works.

2 is a necessary limitation I think, unless we have a fully-worked out spec for how to interpret boolean queries with OR'd date: expressions. I remember they seemed too complicated / undefined to me.

[rickswe]

unless we have a fully-worked out spec for how to interpret boolean queries with OR'd date: expressions. I remember they seemed too complicated / undefined to me.

I'll revisit this later when I work on the budget again and do a work around. Unless you need it open to work on it later, feel free to close it. Thanks