Thank you everyone, for your comments. Let me summarise.
On 2025-07-01 16:46, Jim DeLaHunt wrote:
Hello, fellow GnuCash users!
I have an enhancement request for GnuCash, which GnuCash reminds me
about every time a new month begins. I have finally written it down. I
would like your comments on how useful you think it is, and whether
you see problems with it.
When one enters a part of a date into a date field, GnuCash uses a
date from its context to fill out the rest of the date. For instance,
if the context date is "2025-03-31", and one enters "6", GnuCash
completes the date to "2025-03-06". If one enters "2-6", then GnuCash
completes the date to "2025-02-06".
Currently the date context which GnuCash uses is the current date at
the moment of data entry. Thus, if you launch GnuCash late on
2025-06-30, the context date is 2025-06-30. After your computer's
clock passes midnight, GnuCash changes the context date to 2025-07-01.
I request that the context date be changed to the value currently in
the date field. Often, that is the date most recently entered in that
field. This is the case when entering a batch of transactions in an
account register. Sometimes the date has another value. For example,
when reconciling an account, GnuCash fills the date field for the
reconciliation with the expected next statement date. If a date field
gets created without a valid date value, then it is fine to populate
it with the current date.
...
I heard only one reply which said that this change was a bad idea. I do
not find it to have strong arguments. I heard several comments with
workarounds. Some of those are useful in my case. They reduce the pain
of not having this enhancement. Thus they reduce the chance that I will
make the effort to write the enhancement myself. However, the
workarounds do not say that the proposal is harmful, or that it will
fail to make GnuCash better.
This argument says that the change is a bad idea. On 2025-07-01 17:04,
Ken Pyzik wrote:
...the audit person in me does not like the idea of using back-dates
as a default for entering transactions. I know of several people who
have gotten in a lot of trouble for backdating transactions....
The proposed enhancement will make it easier to use back-dates for
entering transactions. I understand that enforcing audit standards
argues against using back-dates. However, I don't find this persuasive.
First, GnuCash already permits users to enter whatever back-date they
want, as long as they enter it completely. Second, GnuCash already
offers back-dates by default. If you enter one transaction in a register
with a back-date, GnuCash retains that back-date as a default for the
next transaction in that register. If an audit regime seriously wants
GnuCash to help enforce that regime, then it should modify GnuCash to be
more strict. It seems to me that a lax GnuCash which permits violating
GnuCash rules does not get much worse if it changes how it permits
violating GnuCash rules.
Another argument says the change is a bad idea. On 2025-07-01 17:04, Ken
Pyzik wrote:
...if I have transactions going into an account that I have not user
in a long time. If the last date in the date field was over a year
ago since I used that account - I could accidentally enter the
transaction (not realizing that I am entering it to the last year
instead of this year). I am particularly thinking about transactions
that I am entering in let's say Feb. or March on the new year — and
maybe I have not used the account since Oct or Nov of the previous year...
I think this is not a factor in practice. I believe that most users
close GnuCash if they don't use it for a long time. I believe that when
GnuCash starts up, it will set its context date to the current date. I
don't propose to change that behaviour. Thus, when a user goes into an
account which they have not used in a long time, the default date will
be the current date. The completion of "part of a date" will be relative
to that default date. It amounts to the same as current behaviour.
Another argument is, I believe, based on a mistaken premise. On
2025-07-01 17:04, Ken Pyzik wrote:
…most systems I have dealt with always use the current date as the
default when entering transactions. Having GNUcash be uniquely
different and not use the current date would be, in my opinion,
counterintuitive.
GnuCash already breaks this expectation. As mentioned above, If you
enter one transaction in a register with a back-date, GnuCash retains
that back-date as a default for the next transaction in that register.
Remember, we are not talking about what default date GnuCash offers, we
are talking about how GnuCash turns partial dates into complete dates.
And, I can't speak to the systems which Ken uses, but the systems which
I use have not trained me to expect the current date as a default.
Turning to the variety of comments which suggest workarounds, I
appreciate the suggestions, but they do not deliver what I am proposing.
The value to me is letting me enter back-dates with fewer key presses,
especially having to move my fingers to hit the correct digit key for
the past month, followed by the hyphen key. They also do not claim that
the proposed change will fail to improve GnuCash. But of the
workarounds, the most useful was suggested by Patrick James on
2025-07-02 13:21:02 EDT in the bug report[4]:
In the register date field, if one enters
X[
Where X is a day number, for example: 15[
then the X day of the prior month is completed, so the example is the 15th of
last month. Since we're presently in July, 15[ is completed as 2025-06-15.
Similarly, X] is the selected day next month, so 15] today would be completed
to 2025-08-15.
Patrick does make an interesting point:
This behavior, hopefully, would remain rooted in the current context, not
change to the requested context.
If this change to completion of part of a date is adopted, how should
the various date entry shortcuts[5] behave? Do they continue to operate
relative to the current date, or do they change to operate relative to
the displayed date? Given the number of messages suggesting date entry
shortcuts, it is possible that they are more heavily used than partial
dates. Thus changing that behaviour would be more disruptive than
leaving it unchanged.
Is it sensible to think of partial date entry as a different concept
than date shortcuts, or are they the same thing conceptually? This
informs whether they can behave differently, or if they should be have
similarly.
I will summarise this thread in the enhancement request bug report[3].
On 2025-07-01 16:46, Jim DeLaHunt wrote (original post, continued):
...The date picker UI should likewise start with the date value
currently in the date field.
This benefits me primarily when I enter a batch of transactions from a
previous month by hand in an account register. If I manage to enter
the transactions before the end of the month, then the current month
matches the transaction month, and I only need to enter a day number.
But as soon as the month ends, I have to enter two numbers: month and
day. And every new year, I have to enter a full date for every
transaction. But GnuCash typically populates a register's date entry
field with the most recently-entered value. This enhancement means I
would only need to enter the extra fields once, then I could enter
just the day number for the rest of the batch.
A consideration is whether there are people who depend on the current
behaviour and would be impacted by the enhancement difficult. For
instance, someone who opens GnuCash for the first time in a month and
enters a batch of transactions might be impacted. I suspect that the
impact would be limited. When they enter the first date in a batch,
they might have to supply a more complete date. But then that date
becomes the existing value in the field, and so they can enter just
the day number for the rest of the batch.
The documentation appears not to promise any particular context date.
Manual sections 6.2.1 "Entering Directly in the Register Window"[1]
and 6.4. "Multiple Split Transactions"[2] both say, "It is also
possible to type in the date or part of the date and let GnuCash fill
the rest." It doesn't say how GnuCash fills in the rest.
Thank you for the comments! Please keep them coming.
—Jim DeLaHunt
[1] <https://lists.gnucash.org/docs/C/gnucash-manual/trans-enter.html>
[2]
<https://lists.gnucash.org/docs/C/gnucash-manual/trans-multi-enter.html>
[3] <https://bugs.gnucash.org/show_bug.cgi?id=799630>
[4] <https://bugs.gnucash.org/show_bug.cgi?id=799630#c1>
[5]
<https://www.gnucash.org/docs/v5/C/gnucash-guide/chapter_txns.html#:~:text=2.9.2.4.%C2%A0Using%20Entry%20Shortcuts>
_______________________________________________
gnucash-user mailing list
[email protected]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
