After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 497831 - Can't change the date of a transaction with certain locales
Can't change the date of a transaction with certain locales
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: Register
2.2.x
Other All
: Normal normal
: ---
Assigned To: gnucash-ui-maint
gnucash-ui-maint
: 506505 536836 641200 653110 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-11-18 09:34 UTC by Oxmosys
Modified: 2018-06-29 21:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Diff for po/pl.po between 2.2.3 and 2.2.7 (11.36 KB, application/octet-stream)
2008-11-23 19:53 UTC, Oxmosys
Details
Diff for po/pl.po between 2.2.3 and 2.2.7 (125.16 KB, text/x-diff)
2008-11-23 21:15 UTC, Oxmosys
Details

Description Oxmosys 2007-11-18 09:34:58 UTC
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
Comment 1 Oxmosys 2008-02-16 17:59:46 UTC
This bug can still be reproduced with 2.2.3 version in Hardy alpha 4
Comment 2 Jiri Janovec 2008-05-30 10:56:45 UTC
Visible even in KDE 3.5.9 with Kubuntu 8.04
Comment 3 Oxmosys 2008-09-23 13:32:24 UTC
Fixed for pl_PL locale in 2.2.6, but the bug still exist for :

cs_CZ
ne_NP
ta_IN
Comment 4 Vitezslav Kotrla 2008-11-23 19:19:51 UTC
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?
Comment 5 Oxmosys 2008-11-23 19:52:40 UTC
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.
Comment 6 Oxmosys 2008-11-23 19:53:29 UTC
Created attachment 123281 [details]
Diff for po/pl.po between 2.2.3 and 2.2.7
Comment 7 Vitezslav Kotrla 2008-11-23 20:09:25 UTC
(Thanks, but it seems like you've attached wrong file, I can see only some lspci stuff.)
Comment 8 Oxmosys 2008-11-23 21:15:34 UTC
Created attachment 123284 [details]
Diff for po/pl.po between 2.2.3 and 2.2.7

Indeed, sorry ;)
Comment 9 Vitezslav Kotrla 2008-11-25 07:19:16 UTC
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).
Comment 10 Waraqa 2009-04-15 03:36:55 UTC
I can confirm this bug for ar_SA locale.
I'm using GnuCash 2.2.6 on Debian.
Comment 11 Oxmosys 2010-02-25 02:15:09 UTC
Still not fixed in gnucash 2.3.9 development release.
Comment 12 Geert Janssens 2011-01-21 14:31:14 UTC
*** Bug 506505 has been marked as a duplicate of this bug. ***
Comment 13 Geert Janssens 2011-01-21 14:51:56 UTC
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.
Comment 14 Geert Janssens 2011-01-21 14:55:25 UTC
*** Bug 536836 has been marked as a duplicate of this bug. ***
Comment 15 Geert Janssens 2011-06-21 17:07:51 UTC
*** Bug 653110 has been marked as a duplicate of this bug. ***
Comment 16 Radim Tobolka 2011-07-30 10:01:10 UTC
Same problem here with GnuCash 2.4.2 and locale cs_CZ.utf8. The proposed workaround, however, works :-)
Comment 17 Geert Janssens 2012-06-29 15:03:04 UTC
*** Bug 641200 has been marked as a duplicate of this bug. ***
Comment 18 Geert Janssens 2014-02-22 17:23:25 UTC
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 ?
Comment 19 Matěj Cepl 2014-02-24 00:29:31 UTC
(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?
Comment 20 Geert Janssens 2014-02-25 14:52:21 UTC
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.
Comment 21 John Ralls 2018-06-29 21:54:38 UTC
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=497831. Please continue processing the bug there and please update any external references or bookmarks.