GNOME Bugzilla – Bug 338911
Cannot enter 4-digit years with empty LANG or LANG=C
Last modified: 2018-06-29 21:01:43 UTC
Confirmed in SVN 1.9.5, r13796 Steps to reproduce: 1. Launch GnuCash with an empty LANG variable, $ LANG= /path/to/gnucash/bin/gnucash 2. Check the Preferences to ensure that the Date/Time format is Locale - 07/31/05 3. Open a register window and try to enter this date: 04/18/2006 GnuCash will show Saturday 18 April 2020 in the status bar. Tab out of the date field and the register shows 04/18/20. This only happens if LANG is empty and Date/Time preferences are set to the Locale.
But is the behaviour of an empty LANG actually defined in any way? Also, I guess this behaviour refers to unset LANG and LC_ALL and LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, LC_TIME. But setlocale(3) claims that the POSIX locale would be LANG="C" or LANG="POSIX", not an unset env variable. In fact, setlocale(3) claims "The first existing environment variable is used. If its value is not a valid locale specification, the locale is unchanged, and setlocale returns NULL." which in this case should mean the locale is unchanged when setlocale() is called -- but the original locale is probably unknown here? You should try to find out the actual locale that is in effect before (and also after) the setlocale() call when LANG is unset.
(Should have added that this is Debian bug #316032) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316032 The bug is still present using the command line: $ LANG=C /path/to/gnucash/bin/gnucash
According to http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html the POSIX locale value for the keyword D_FMT is "%m/%d/%y", where %y is used by strptime, according to the GNU C Library Reference as """The year without a century as a decimal number (range 0 through 99). Leading zeroes are permitted but not required. Note that it is questionable to use this format without the %C format. The strptime function does regard input values in the range 68 to 99 as the years 1969 to 1999 and the values 0 to 68 as the years 2000 to 2068. But maybe this heuristic fails for some input data. Therefore it is best to avoid %y completely and use %Y instead.""" So actually this looks like a standard conforming parse of a date.
Thanks for checking on that. What we need then is some kind of wrapper or error handler that at least makes the user aware of why this is happening. Maybe when gnucash starts it can check for such a locale and cause a prompt, or check the length of the string to be parsed in the register ... Changing severity to wishlist.
In my opinion no such feature is necessary. The user should eigher choose a reasonable locale, GnuCash date format or stick to the standard. So I also vote for closing :D
Should we close this as NOTGNOME? Or what is the particular enhancement request to gnucash?
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=338911. Please update any external references or bookmarks.