> 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
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
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
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
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
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
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
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
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
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
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
11 matches
Mail list logo
