GNOME Bugzilla – Bug 332318
'Birth Date' has an invalid format.
Last modified: 2013-09-13 01:00:10 UTC
Evolution seems to be imcompatible to itself. Bad. :-/ Steps to reproduce: * Have a Contact that was saved in previous Evo versions, with a Birthday set (entered using previous Evo versions). * Edit that Contact, like add a note. I get this error message: Invalid contact. The contact data is invalid: 'Birth Date' has an invalid format. Please note, that I did *not* change the Birth Date. It is left untouched just like Evo put it into the Birthday field. Birth Date is displayed in the Birthday field by Evolution: 30/10/81 This is a major issue, that never ever may happen.
works fine here (evo 2.5.91 compiled three days ago), cannot reproduce. adding a note to a contact in my personal calendar, click "ok", and it gets saved perfectly.
OK, a bunch of notes. That displayed date indeed is correct, according to my locale: LC_TIME=en_GB.UTF-8 It is supposed to be October 30, 1981. * When opening the Contact Editor, Evo displays the date correct according to LC_TIME (dd/mm/yy for en_GB). * When saving (actually, every time that date is being checked) however, Evo obviously insists on using LC_TIME en_US (which is mm/dd/yy). This is 100% reproducible. Evo sets the field to dd/mm/yy itself, but accepts mm/dd/yy *only*. Obiously date input and date output are bound to different locales. Most likely related to bug 250754, which was "fixed" recently. Probably a duplicate of bug 329356. Env vars that may be related: LANG=en_US.UTF-8 LC_TIME=en_GB.UTF-8
As per discussion with Sebastien Bacher, we consider this to be GNOME 2.14.0 BLOCKER. Discussing a little further with the Evo team, before doing so, though.
As per discussion on IRC, GNOME 2.14.0 blocker.
Oh, and confirmed by bug 329356 (ignore the crash for a moment ;)
Fix commited.
Created attachment 60021 [details] [review] Fixes the bug.
Created attachment 60024 [details] [review] Fixes the bug.
The second attachments fixes this issue. However, note: * To not risk breaking API freeze, the %x format was added. This may lead to confusion in some special cases. The format array will be checked in order, with the first format matching the (possibly user provided) string creating the struct tm. With the above given example (yes, this really is my life setup ;) of LC_TIME in en_GB format (dd/mm/yy) and LANG in en_US format (mm/dd/yy), now both formats are valid input, and the text field is left as is with a valid input. Entering 31/01/06 (Jan 1st, en_GB format) is correct input. Using the en_US format 01/31/06 is correct, too. The text input field is not rewritten during the edit process. The date widget is always right. ;) Entering either of the above, correctly picks Jan 1st. While the above is unambiguous to a human, Jan. 2nd is not. This may lead to user confusion, in one particluar yet (hopefully) rare case: a) The user different LANG and LC_TIME env vars, who share the very same delimter but have different order of values, and b) the user is used to manually enter the (wrong) LANG format, rather than the specifically set LC_TIME format. This includes, 01/31/06 is correct one day (LANG as fallback used), but the same format 02/01/06 one day later actually is not Feb 1st, but Jan 2nd -- cause LC_TIME matches, and we do not fall back to the (inappropriate) LANG. When opening the Contact Editor, LC_TIME format is used always. A long term fix likely should remove the translated string format[2] for good, and correct format[1]. Making the translators localize a string like this IMHO is the wrong thing to do anyway. %x got a localized version already.
Anyway, in a sane environment, this just works. :-) Thanks for the very fast fix, chen.
*** Bug 332518 has been marked as a duplicate of this bug. ***
*** Bug 332575 has been marked as a duplicate of this bug. ***
*** Bug 332710 has been marked as a duplicate of this bug. ***
*** Bug 344516 has been marked as a duplicate of this bug. ***