GNOME Bugzilla – Bug 332518
Date validation always fails
Last modified: 2013-09-13 00:51:59 UTC
Please describe the problem: When I try to add a new Appointment, evolution never accepts the dates I enter. It does that even if I use the calender widget to enter the date. "Validation error: Start date is wrong" and "Invalid Date Value". This makes it impossible to add any new appointments. Wonder whether this is a locale problem? Using en_IE.utf8, but have been using this for a long time now. Evolution is 2.5.91 Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Yes Other information:
Indeed, this is influenced by locale. export "LC_ALL"="somelocale" before executing evolution influences whether it fails or not. Works ----- en_US.utf8 en_US de_DE de_DE.utf8 Doesn't work ------------ de_CH.utf8 de_CH en_IE.utf8 en_IE
I believe, this is a known issue in Eo 2.5.91 and already fixed in CVS. The problem is, that Evo in that versions displays the date value according to your LC_TIME env var (which is dd/mm/yy for en_IE), but accepts date values only according to the translation (afected by LANG env var). Since there is no specific translation for en_IE, this defaults to mm/dd/yy... Please try the latter mm/dd/yy format when entering a date. This should work. The problem is, that due to this Evo does not accept the date value Evo generated itself in the very same input field... This is fixed in CVS and respects LC_TIME for both now. Alexander, if this does not fix your isue, please reopen this bug immediately and give more detailed steps to reproduce the issue. Thanks. *** This bug has been marked as a duplicate of 332318 ***
What you say mostly describes what I have chased the problem down to. It seems that evo validates the date entered against LANG instead of LC_TIME. I will test that more precisely, but don't have the time now.
Thanks, Alexander. If you built Evo from source, you could apply the patch attached to bug 332318 for e-d-s and see, if this fixes the issue for you.
Indeed I do not experience this problem anymore with 2.13.92.
OK, great. Thanks for verifying, Alexander.