[GNC] Bad date not caught

[Stephen M. Butler]

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.Butler51 at gmail.com
kg7je at 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 <stepbystepfarm at 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 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.
> _______________________________________________
> 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.