No possibility to change a date other than current with locale cs_CZ ne_NP ta_IN

Please describe the problem:
When using Gnucash with one of these locales :

cs_CZ
ne_NP
pl_PL
ta_IN

It's impossible to change the date of a transaction inside of the registry. I tested all Gnucash locales and these 4 locales are the only one affected by this problem.

Steps to reproduce:
1. Open Gnucash with one of the listed locales Ex. LANG=cs_CZ.UTF8 /usr/bin/gnucash
2. Go to one account that already contain transactions.
3. Try to change the date of one of the transactions with the mouse.

Actual results:
I can't choose another date, it doesn't work.

Expected results:
The new date should be selected and replace the old date.

Does this happen every time?
Yes

Other information:
It has been tested on Linux Ubuntu Gutsy 7.10, Gnucash 2.2.1-1ubuntu4

This bug can still be reproduced with 2.2.3 version in Hardy alpha 4

Visible even in KDE 3.5.9 with Kubuntu 8.04

Fixed for pl_PL locale in 2.2.6, but the bug still exist for :

cs_CZ
ne_NP
ta_IN

I'm using Debian gnucash package (2.2.6-2) and can confirm that this bug exists for cs_CZ.UTF-8.

How has been pl_PL fixed? I'd like to fix cs_CZ, what needs to be done?

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.

Created attachment 123281
Diff for po/pl.po between 2.2.3 and 2.2.7

(Thanks, but it seems like you've attached wrong file, I can see only some lspci stuff.)

Created attachment 123284
Diff for po/pl.po between 2.2.3 and 2.2.7

Indeed, sorry ;)

Well I went several times through cs.po, but found no clue. The only variables found there are %s and %d, nothing special in terms of strftime(), so I guess problem lies in gnucash source, not in message catalog (.po file).

I can confirm this bug for ar_SA locale.
I'm using GnuCash 2.2.6 on Debian.

Still not fixed in gnucash 2.3.9 development release.

*** Bug 506505 has been marked as a duplicate of this bug. ***

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.

*** Bug 536836 has been marked as a duplicate of this bug. ***

*** Bug 653110 has been marked as a duplicate of this bug. ***

Same problem here with GnuCash 2.4.2 and locale cs_CZ.utf8. The proposed workaround, however, works :-)

*** Bug 641200 has been marked as a duplicate of this bug. ***

I have just committed a fix for the cs_CZ locale [1]. I was almost correct in comment 13 regarding the '-' modifiers in this date format. It is however the low level glib function strptime that fails to parse this modifier, not the gnucash code.

I have worked around this in gnucash by stripping the modifier before passing the format string to strptime.

[1] https://github.com/Gnucash/gnucash/commit/6925192a

The other failing date formats (ne_NP and ta_IN) still need more thought. There are other format definitions that have a similar layout but were not mentioned here yet.

In some more detail: the %A format specifier represents the day of the week, so these would for example match a date string similar to
mon 22 Feb 2014
With the weekday and month displayed in the locale language.

This case is not handled properly at all right now. I can fairly easily fix this to handle the case where the full date is entered like the example.

But I don't know how to handle partially entered dates. GnuCash tries to make a best guess to what the user really meant as date. How do people in the ne_NP and ta_IN typically enter dates ? Do you actually type the day-of-week part as well, or do you just type 22 feb 2014 ? Or is this part always explicitly entered or only sometimes ?

(In reply to comment #18)
> It is however the low level glib function strptime that fails to parse this
> modifier, not the gnucash code.

Is there a glib bug for this?

Gnu's libc doesn't consider this a bug apparently but rather a documented limitation:
http://www.gnu.org/software/libc/manual/html_node/Low_002dLevel-Time-String-Parsing.html#Low_002dLevel-Time-String-Parsing

I haven't searched further for bug reports regarding this.

Tested with LANG=ne_NP.UTF-8 and GnuCash maint. Works fine, probably because we now use boost::date_time for date parsing instead of libc's strptime.