Launchpad has imported 22 comments from the remote bug at
https://bugs.gnucash.org/show_bug.cgi?id=497831.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2007-11-18T09:35:02+00:00 Saivann Carignan wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/1

------------------------------------------------------------------------
On 2008-02-16T17:59:50+00:00 Saivann Carignan wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/4

------------------------------------------------------------------------
On 2008-05-30T10:56:49+00:00 J-janovec wrote:

Visible even in KDE 3.5.9 with Kubuntu 8.04

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/5

------------------------------------------------------------------------
On 2008-09-23T13:32:28+00:00 Saivann Carignan wrote:

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

cs_CZ
ne_NP
ta_IN

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/7

------------------------------------------------------------------------
On 2008-11-23T19:19:55+00:00 Vítězslav Kotrla wrote:

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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/8

------------------------------------------------------------------------
On 2008-11-23T19:52:44+00:00 Saivann Carignan wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/9

------------------------------------------------------------------------
On 2008-11-23T19:53:33+00:00 Saivann Carignan wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/10

------------------------------------------------------------------------
On 2008-11-23T20:09:29+00:00 Vítězslav Kotrla wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/11

------------------------------------------------------------------------
On 2008-11-23T21:15:38+00:00 Saivann Carignan wrote:

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

Indeed, sorry ;)

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/12

------------------------------------------------------------------------
On 2008-11-25T07:19:20+00:00 Vítězslav Kotrla wrote:

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).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/13

------------------------------------------------------------------------
On 2009-04-15T03:36:59+00:00 Linux-uae wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/14

------------------------------------------------------------------------
On 2010-02-25T02:15:13+00:00 Saivann Carignan wrote:

Still not fixed in gnucash 2.3.9 development release.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/15

------------------------------------------------------------------------
On 2011-01-21T14:31:18+00:00 Geert Janssens wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/16

------------------------------------------------------------------------
On 2011-01-21T14:52:00+00:00 Geert Janssens wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/17

------------------------------------------------------------------------
On 2011-01-21T14:55:29+00:00 Geert Janssens wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/18

------------------------------------------------------------------------
On 2011-06-21T17:07:55+00:00 Geert Janssens wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/19

------------------------------------------------------------------------
On 2011-07-30T10:01:14+00:00 Radim wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/20

------------------------------------------------------------------------
On 2012-06-29T15:03:08+00:00 Geert Janssens wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/21

------------------------------------------------------------------------
On 2014-02-22T17:23:29+00:00 Geert Janssens wrote:

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 ?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/22

------------------------------------------------------------------------
On 2014-02-24T00:29:35+00:00 Matej wrote:

(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?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/23

------------------------------------------------------------------------
On 2014-02-25T14:52:25+00:00 Geert Janssens wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/24

------------------------------------------------------------------------
On 2021-03-23T22:55:23+00:00 Jralls wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/152864/comments/25

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/152864

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnucash/+bug/152864/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to