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.
