The parser should know the local date format for the user. That would
resolve the M/D/Y, D/M/Y, and Y/M/D format issue.
Stephen M Butler
stephen.m.butle...@gmail.com
kg...@arrl.net
253-350-0166
-------------------------------------------
GnuPG Fingerprint: 8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8
On 10/12/23 16:27, john wrote:
Rather than banging on about the validity or lack thereof of 31 December 1999,
which isn't really Fred's complaint, it would be more useful to explain that
the date parser fires on every keystroke when typing a date in the Date Edit
text box. That makes it unhelpful to raise a dialog every time the entered date
isn't valid because that will be true on most of the keypresses when entering a
date. Not to say that it's not feasible to do so, just that that's how it works
now. There's already an event handler for when the GncDateEdit loses focus,
that just needs to be wired up to know that the entered date wasn't used so it
can put up a message box warning the user.
As I was looking through the code I saw that the intent was to use *today's*
date, not time 0, when the date didn't parse correctly. That at least will
keep the duplicated transaction in view and was an easy fix, so I fixed it.
Another more involved fix would be to make the date parser a bit more liberal
about delimiters and formats; the only slightly minor difficulty is ordering
ambiguous sequences: for example 21-10-23 could be 21 October 2023 or 23
October 2021 and 5/7/9 could be the 9 July 2005, 7 May 2009, or 5 July 2009.
Regards,
John Ralls
On Oct 12, 2023, at 09:51, Michael or Penny Novack <stepbystepf...@comcast.net>
wrote:
On 10/12/2023 10:40 AM, Fred Tydeman wrote:
In an account, I clicked on Duplicate of a transaction.
I got a small popup with the date field highlighted.
I typed in 5.19.21 (instead of the correct 5/19/21) and pressed enter.
That got me the transaction duplicated, but with the
date of 12/31/1969.
Seems like the code should warn me about bad date.
LOL --- it did, sort of.
The problem is that you didn't know the special meaning of 12/31/1969 Now if
the program had returned 00/00/0000 you would have understood that you had a
bad date. In other words, ZERO
By a convention adopted long ago, computers measure time in microseconds since "time
zero" which was chosen to be midnight, 12/31/69 (before Y2K we tended to write years two digit
if we meant in the 1900's). That makes the "zero date" a VALID date (00/00/0000 would not
be valid in a field expecting a date)
Michael D Novack
_______________________________________________
gnucash-user mailing list
gnucash-user@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.
_______________________________________________
gnucash-user mailing list
gnucash-user@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.
_______________________________________________
gnucash-user mailing list
gnucash-user@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.
