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): gnucash-2.0.5-3.fc7.i386 gnucash-2.0.5-3.fc7.x86_64 How reproducible: always Actual results: Date input fields do not work correctly. Expected results: Date input fields do work correctly.
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.
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 anyway. 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).
See: http://sourceware.org/bugzilla/show_bug.cgi?id=4772 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.
So, there is no actual fix possible for gnucash, yet it's assigned there?
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 discussion.
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: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.
Closing, then.