Comment 17 for bug 152864

Confirmed for 2.4 on Fedora 14.

Simple way to test (from bug 506505):
* Run GnuCash with the following command:
   LC_ALL=cs_CZ.UTF-8 LANG=cs_CZ.UTF-8 gnucash
* Check that the Date/Time date formate preference is set to "locale"
* Try to enter a date in the register.
=> This will always jump back to the current date

There is a workaround for those hitting this bug in their daily work:
Set the Date/Time date format preference to anything but "locale". Then you will be able to enter dates normally.

(In reply to comment #5)
> I'm not a expert but I'm pretty sure that things needs to be fixed in "po" and
> folder in the source because this is where pl.po is. I'm attaching the
> difference in po/pl.po between 2.2.3 and 2.2.7 in case that might be useful to
> you.
It is very unlikely this has something to do with the po file. The po file holds translations for all text messages and strings used in GnuCash. It has no effect on the interpretation of the date format.

I suspect this bug is caused by an improper parsing of the "short date format string" for certain locales.

This format string differs per locale. For example:
C (US English): %m/%d/%y
nl_BE : %d-%m-%y
cs_CZ : %-d.%-m.%Y
ne_NP : %A %d %b %Y
pl_PL : %d.%m.%Y
ta_IN : %A %d %B %Y

As you can see, these formats differ wildly. From first looks (but I haven't looked in the actual code) I think cs_CZ fails because the dashes ("-") are mistakenly interpreted as field separators, while they are actually format modifiers. The pl_PL locale seems quite normal, and has been reported to work. The ne_NP and ta_IN locales are different in two ways: their format string consists of 4 fields (instead of the usual 3) and they are separated by spaces.