GNOME Bugzilla – Bug 794030
relative date functions compute wrong day of month
Last modified: 2018-06-30 00:05:12 UTC
The file /src/app-utils/date-utilities.scm contains eight functions by the names of get-{one-month,three-months,six-months,one-year}-{ago,ahead}, which all contain a statement like (if (> month-days (tm:mday now)) (set-tm:mday now month-days)) Note that in the first of these functions the variable is called month-length instead of month-days, otherwise they are the same. The issue is that all these functions should have a "<" instead of ">" in this statement. The condition is meant to prevent the situation where e.g. on May 31, after substracting one month from the date, one would end up with the invalid date "April 31". In these cases, the day-of-month field should be set to the last valid number (so in this case one would end up with "April 30"). This correction should of course occur if the number days in the current month is *less* than the current day-of-month, not more. I think this issue can be fixed by simply replacing ">" by "<" in these eight places.
Hi Fabian, These functions are not actually present in any default reports, hence, are not generally used. Do you have a use case for them, in a private report? If not I'd suggest they just be removed. In the future we aim to remove date-utilities.scm altogether.
Hi Chris, My use case is as follows: I'm running a regular monthly Income & Expenses report that I export to PDF and save at the end of every month. However, my salary always arrives on one of the last days of the month, making the month-to-date I&E report display a net loss on any day before that. I found that switching to a "running month" scheme (i.e., having the report run from "today's date last month" until today) gives me a much better overview to determine at a glance whether I'm over or under budget. Note that I did not create a custom report for this but instead directly edited the source code of the standard I&E report, which I found easier by far. I am a programmer but not really fluent in scheme, so reading and modifying existing code for me is much easier than writing it from scratch. I imagine this situation is not too uncommon. My suggestion therefore would be to remove these functions from date-utilities.scm if they are not needed anywhere, but include maybe one of them in hello-world.scm for illustrative purposes, so people like me can copy&paste them from there. What do you think?
Hi Fabian If you're using these functions then I'd think there's a benefit to fixing them, adding test cases, and even adding them onto the default relative date selectors which will prevent bitrot. The main burden will fall upon the scheme maintainers. I believe the strings have already been translated a long time ago. What would the devs recommend?
Hi all, Just a side remark: While googling this before, I encountered this discussion: https://gnucash.uservoice.com/forums/101223-feature-request/suggestions/1569035-add-tomorrow-to-the-list-of-symbolic-dates-for-d I agree with cstim there that having too many options in the dropdown box could hinder usability. Structuring the dropdown list with optgroup's would help, but I guess that would entail fiddling with the definition of gnc:make-date-option.
fixed (in upcoming 2.6.20 and 2.7.8) but the code is still inaccessible in default reports.
Inaccessible or just not used? IOW it's available if someone wants to use it in a default report, right?
JRalls- Correct, they are unused in default reports.
So since your PR is merged I'm closing this. Thanks.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=794030. Please update any external references or bookmarks.