[GNC] What do you think of this enhancement: Complete "part of a date" with date already in field, not date of entry?

Sat Jul 5 17:40:49 EDT 2025

Jim — as I read through your entire post - I see you have given this a lot of thought!

In reality, I don't believe this is a big deal for most people.  I think the crux of this enhancement lies with those who may be entering a lot of transactions.  In other words, if I am only entering my personal transactions - and I am only doing 20-30 transactions in a month, I think this enhancement has little impact.

On the other hand, if you are entering hundreds of transactions per month — and waiting until the end of the month to enter them — then I can see where the enhancement might help that person or persons out.

The real bottom line is this — I believe (maybe incorrectly) that most people may not see the value in adding this change and much as you do, and, as such — if it does not add a lot of additional value for most people — I would say leave the system as is.

That being said, if it means that much to you that you are willing to go to bat for it this badly — most people probably won't mind if the change is made — since they will probably just learn to adapt to either use it or not!

Ken

________________________________
From: gnucash-user <gnucash-user-bounces+pyz01=outlook.com at gnucash.org> on behalf of Jim DeLaHunt <list+gnucash at jdlh.com>
Sent: Saturday, July 5, 2025 1:24 PM
To: gnucash-user at gnucash.org <gnucash-user at gnucash.org>
Subject: Re: [GNC] What do you think of this enhancement: Complete "part of a date" with date already in field, not date of entry?

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
gnucash-user at gnucash.org
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.