I'm runniing GnuCash v3.4 on Linux Mint Tara(19.0 (Ubuntu 18.04) . If I enter a transaction from an asset account register and enter the date as 27/02/2019 the transaction is recorded as 27/02/20 not 27/02/2019 and if I select the dropdown calendar selector the year shows in that as 2020. Only if I enter the date as 27/02/19 does it set the right date. The Date-Time settings in the preferences is "Locale 31/07/13". I also remember this occurring in v2.6. It has never bugged me enough to report it as a bug, I just adapted my practice to avoid it previously If I change the Date-Time setting to "UK 31/07/2013" then it all seems to work as expected. I can enter either 27/02/19 or 27/02/2019 and the correct date is now set so it appears to be a subtlety in the interaction of the locale date format setting and the parsing of the string typed in.
Bugs 137017 and 497831 may be related.
I don't think either of the bugs is related. The first has to do with the way GnuCash stores dates and the other is a locale issue with two asian locales, Nepali and Tamil. In this case the problem appears to be that GnuCash is being too literal in doing what you asked it to. You--and I imagine most users who pick a two-digit date format--expect that to apply for display but not for input. It's a reasonable expectation, and it would be equally reasonable (Geert's going to cringe) to have a separate input option that specifies only the order of year, month, and day when they can't be disambiguated, e.g. what does 10/11/12 mean?
:) The key point indeed is we have different expectations for input and display behaviour while gnucash treats them the same. On the other hand all date formats we currently have are unambiguous as well so I don't perceive that alone as a compelling reason to add the extra option: this particular bug can also be fixed by being more liberal about the year part of the formats and accept two or four digit years regardless of what the format specifier says. That is not to say I'm against adding such an option per se. The importers already do treat dates that way. Extending this to all of GnuCash would help making the date experience more consistent. What I do want though is to think this through/discuss it more thoroughly so the final implementation will be sufficiently flexible and user friendly. Just as background data points I have also seen a few other date ui implementations: - odoo (the other accounting package I use) accepts about any date you input (2-digit, 4-digit, any date separator). It assumes the date order based on the date formate for the language you have set for the interface. (So for English it will assume M/D/Y for Dutch it will assume D/M_Y). For display it will use the date format for that same language. So you don't have an option to change your date format independently from the language. - LibreOffice Calc has a very elaborate date formatting panel. You can pick a language and based on that language/locale you will get a list of possible date formats. These range from short dates to dates with full names in the language/locale. In addition and regardless of the language/locale you select it will also offer a couple of fixed formats (like the iso format). This selection affects both display and input. That means what you selected will be used for display and your input will be parsed against this format. If your input doesn't match the selected format, the input will also be matched against your current locale's date format. If matched the date will be parsed anyway according to this locale format. That's all I have time for now :(
