Re: [GNC] Bad date not caught
> On Oct 13, 2023, at 11:32, David G. Pickett via gnucash-user > wrote: > > String to date parsers provide a way to tell if the entire string was not > digested, see 'man strptime' that says it returns a pointer to where it > stopped, should be at the end of the string. They do, and adding that check is part of what I pushed yesterday: https://github.com/Gnucash/gnucash/commit/44c278a82c692b5b591eccaf052952b3cd248084 But the rest of that function is a bit goofy and regardless strptime is very fussy: If you tell it to parse the date with %m/%d/%Y and pass in--as Fred did--5.19.21--it will return NULL indicating that the parse failed. We can do much better. Regards, John Ralls ___ 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.
Re: [GNC] Bad date not caught
String to date parsers provide a way to tell if the entire string was not digested, see 'man strptime' that says it returns a pointer to where it stopped, should be at the end of the string. ___ 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.
Re: [GNC] Bad date not caught
There are two problems with that: Not everyone uses their locale date format. For example the US locale format is MDY but there are plenty of us former military types who do DMY because that's how the military does it. The other thing is that brain-farts happen. I enter DMY 99 44/100% of the time but every once in a while something happens and it goes in YMD. Sometimes it's even MDY. There's even a CS paradigm for this: Be liberal accepting input and strict formatting output. Regards, John Ralls > On Oct 12, 2023, at 16:34, Stephen M. Butler wrote: > > 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 >>> 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/ 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/ 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. ___ 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.
Re: [GNC] Bad date not caught
That would be because the FAA has been trying and failing to upgrade their IT for darn near 50 years. MMDDYY was the standard way to code dates in the 1960s. Getting that fixed was what the Y2K apocalypse was about. But while it's a nice standard that works a tread for the backends it's not something to impose on users. If you want to write dates as MM-DD-YY GnuCash should accept that. Regards, John Ralls > On Oct 12, 2023, at 17:02, Dean Gibson wrote: > > Actually,, ISO8601 describes the valid (& preferred) date representations. > Anything with dashes is presumed to be -MM-DD. Of course, just because > this is an international standard, doesn't mean that everyone (including > governments) follows it. This includes the US FAA. which presumes MM-DD-YY. > > So much for standards! I guess ISO8601 is pretty new (35 years ago) for some > organizations! > > On 2023-10-12 16:27, john wrote: >> ... >> >> 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 >> > ___ > 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.
Re: [GNC] Bad date not caught
I shudder at the thought, but it is entirely possible they were (and still are) 'grandfathered' in! Regards, Adrien On 10/12/23 7:02 PM, Dean Gibson wrote: This includes the US FAA. which presumes MM-DD-YY. So much for standards! I guess ISO8601 is pretty new (35 years ago) for some organizations! ___ 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.
Re: [GNC] Bad date not caught
Actually,, ISO8601 describes the valid (& preferred) date representations. Anything with dashes is presumed to be -MM-DD. Of course, just because this is an international standard, doesn't mean that everyone (including governments) follows it. This includes the US FAA. which presumes MM-DD-YY. So much for standards! I guess ISO8601 is pretty new (35 years ago) for some organizations! On 2023-10-12 16:27, john wrote: ... 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 ___ 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.
Re: [GNC] Bad date not caught
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 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/1969Now if the program had returned 00/00/ 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/ 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.
Re: [GNC] Bad date not caught
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 > 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/1969Now > if the program had returned 00/00/ 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/ 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.
Re: [GNC] Bad date not caught
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/ 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/ 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.
Re: [GNC] Bad date not caught
Hi, On Thu, October 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. What is "bad" about 12/31/1969? Do you have something against the 60s? Something against new year's eve? Or just don't like the coming 1970s? A "Bad Date" (in this context -- not some nightmarish dinner-and-a-movie horror) would be "12/32/1969". In all seriousness, GnuCash can't necessarily know if you MEANT to type 12/31/1969 or if it's due to the parsing of your input that results in '0'. Clearly, 12/31/1969 is not what you INTENDED, but I wouldn't necessarily say it is a "bad date". Having said that, there IS code in GnuCash that prevents adding new transactions earlier than some specified historic period (e.g. 90 days ago). If you have that feature turned on (it is NOT turned on by default) and this happened, then that would absolutely be a bug. > I am running GnuCash 4.14 > on Linux Fedora 37 > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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.
[GNC] Bad date not caught
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. I am running GnuCash 4.14 on Linux Fedora 37 ___ 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.
