Relative date in periodic transactions is based on Y/1/1

[wgslr]

The documentation for periodic transactions states:

Partial or relative dates (M/D, D, tomorrow, last week) in the period expression can work (useful or not). They will be relative to today's date, unless a Y default year directive is in effect, in which case they will be relative to Y/1/1.

I've found that even without a Y directive, the dates are calculated relative to the 1st of January of the current year rather than relative to the current day.

hledger version

hledger 1.25, linux-x86_64

current behaviour

(executed on 2022-03-14)

$ cat periodic-bug.journal 
~ tomorrow
        assets     -10e
        expenses    10e
$ hledger print -f periodic-bug.journal --forecast -bthismonth
$ hledger print -f periodic-bug.journal --forecast -bthisyear
2022-01-02
    ; generated-transaction: ~ tomorrow
    assets              -10e
    expenses             10e

expected behaviour

The periodic transaction is generated for date 2022-03-15 rather than 2022-01-02.

[Xitian9]

This is an error in the documentation. In fact, partial dates are calculated relative to Y/1/1, but relative dates are calculated relative to the latest date in the journal if any are present, and otherwise relative to today. This behaviour is unlikely to change. Can you let us know what effect you're trying to achieve, and we can let you know how to go about it?

Edit: Sorry, I misread which behaviour was expected and which was seen. Give me a moment to think on this more.

One thing that I can say is that relative dates in periodic transactions are a misfeature, in there because the same code is used for periodic transactions and report spans. They have not been removed because it was assumed that nobody would ever try to use them, so I am very interested in your objective here. If there's a valid use case for relative dates in periodic transactions, we should accommodate them.

[Xitian9]

Okay, it looks like you are correct: periodic transactions are always resolved relative to January 01 of

1. The year declared with the Y directive; or, if not present
2. The current year.

It has been like this for a very long time. Relative dates in periodic transactions are not an area we've paid attention to (and if we pay attention it will probably be to remove them), so I'm presuming it was set up this way for some other reason. Any insight Simon?

https://github.com/simonmichael/hledger/blob/cbdd86f4dc58300b3f06deb986c7f097b8514727/hledger-lib/Hledger/Read/Common.hs#L257-L259

[simonmichael]

Right - support for relative dates in periodic transaction rules is not a feature intended to be used, as it probably wouldn't be very useful; it's just a consequence of reusing --period's parser. The doc is there just to specify how it works if used, it sounds like an edit is needed (will do).

We could make it an error to use them in the journal, effectively creating two flavors of period expression. I'm not sure if that's needed.

Thanks for the report.

[wgslr]

Thanks for the quick responses. I can see how it's not a popular or important feature. The reason I looked at it at all was a bit of a hack: I wanted to reset some account balances to have a cleaner starting point when using --forecast. So I wanted to do something like:

~ tomorrow  Assume full expenses in current month
  assets:current-budget   ==* 0
  expenses

Using a relative date here is convenient, because then I don't need to update the transaction to always be ahead of the newest concrete record.

[wgslr]

Closing the issue was a miss-click, I will leave that decision to you ;)

[simonmichael]

It took a while to investigate all aspects across several issues, but this is indeed a bug - thanks for the report! Forgetting this one I reported it again as #1849, let's finish it over there.