Closed wgslr closed 2 years ago
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.
Okay, it looks like you are correct: periodic transactions are always resolved relative to January 01 of
Y
directive; or, if not presentIt 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?
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.
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.
Closing the issue was a miss-click, I will leave that decision to you ;)
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.
The documentation for periodic transactions states:
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)
expected behaviour
The periodic transaction is generated for date 2022-03-15 rather than 2022-01-02.