Bug 243513 - gnucash has problemshandling date input fields (locale specific?)
gnucash has problemshandling date input fields (locale specific?)
Product: Fedora
Classification: Fedora
Component: gnucash (Show other bugs)
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-06-09 06:15 EDT by Tomasz Kepczynski
Modified: 2014-03-16 23:07 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-14 16:03:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tomasz Kepczynski 2007-06-09 06:15:15 EDT
Description of problem:
I tried to enter date in register column date. I pressed t
(for today) and got: 9 VI 2007. Then I enter the transaction
and then I have: 29 XI 1898. Weird. The field also displays
something different when not selected.
I guess this is locale specific (my locale is pl_PL.UTF-8).
What I noticed in F7 is that date format for Poland was changed
to display month as roman numbers and my guess is this is a
problem. en_US.UTF-8 locale works fine.

Version-Release number of selected component (if applicable):

How reproducible:

Actual results:
Date input fields do not work correctly.

Expected results:
Date input fields do work correctly.
Comment 1 Tomasz Kepczynski 2007-07-09 17:27:20 EDT
This was introduced by date formats for polish locale.
See: http://sources.redhat.com/bugzilla/show_bug.cgi?id=3156
for more information. Reassigning to glibc.

Comment 2 Tomasz Kepczynski 2007-07-10 01:07:32 EDT
I had some second thoufgts on the problem and now
I am not 100% sure it really is glibc. The problem
can be fixed in at least 3 places and I am not
convinced to any of them:
1. D_FMT format as described in #1 but I've just
found out this is strfmt format string and gnucash uses
this in strptime and there is no such string defined
for strptime.
2. strptime should accept D_FMT string with flags
destined for strfmt and parse it ignoring these flags
3. gnucash should not use strptime with format string
obtained by nl_langinfo(D_FMT) but then there is a
question what format string should it use for date
formated in locale specific way?
Maybe we can see how OpenOffice calc does it (if it is
not broken as well).
Comment 3 Tomasz Kepczynski 2007-07-16 04:23:26 EDT
for problems with strptime and especially comment #5
and comment #8 there.
I reassign this as gnucash violates rule specified there.
The correct way gnucash should do this probably is to
use '%x' format string insead of what nl_langinfo(D_FMT)
returns, but this does not work (see comment #9 above).
Now - I believe there is a problem in glibc but gnucash
developers/maintainers should be aware of this as they
may wish to workaround this or discuss with glibc folks
to fix it there.
Comment 4 Bill Nottingham 2007-07-16 13:46:12 EDT
So, there is no actual fix possible for gnucash, yet it's assigned there?
Comment 5 Tomasz Kepczynski 2007-07-16 16:22:26 EDT
Well, the problem is twofold:
1. Gnucash uses string returned by nl_langinfo(D_FMT)
directly in strptime and according to Ulrich Drepper
this is forbidden as nl_langinfo(D_FMT) returns strftime
format string and not strptime format string (see comment
5 in the abovementioned glibc bug.
2. My guess is that correct way to get time in locale
format is to call strptime with '%x' format specifier.
Unfortunately this does not work on Fedora 7 at least in
Polish and Czech locale.
So the fix seems to be needed in both glibc and gnucash.
The problem is that Ulrich seems to be not convinced
by my arguments.
There is a possibility to work around a problem by
stripping format flags unrecognized by strptime in
gnucash. I think this is not the best way of doing
this but still this may be the only option if glibc
developers decide not to fix the problems in strptime.
I guess that the best way would be to discuss the bug in
broader circle but that's the thing I don't now how
to start and as you are (both you and Ulrich) employed
by the same company I hope that you can start the
Comment 6 Bug Zapper 2008-05-14 08:57:45 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Tomasz Kepczynski 2008-05-14 15:47:20 EDT
Two things to be noted here:
1. This problem spawned some heated discussions on glibc
which changed Polish date format. As far as I know it has
been reverted for some time now.
2. Gnucash probably shouldn't blindly rely on glibc functions
for date/time parsing as these functions are not always
guaranteed to work. But this is another story.
So I guess this one can be closed.
Comment 8 Bill Nottingham 2008-05-14 16:03:09 EDT
Closing, then.

Note You need to log in before you can comment on or make changes to this bug.