GNOME Bugzilla – Bug 270607
The time in the mail list (italian locale) is in wrong format
Last modified: 2013-09-10 14:03:47 UTC
Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: Steps to reproduce the problem: 1. Use evolution mailer with italian locale (LANG=it_IT.UTF-8) 2. Read a date and time in the mail table 3. Actual Results: The time should be in 24 hours format Expected Results: The time in in 12 hours format, without the AM/PM indication How often does this happen? Ever Additional Information: Sorry, my english is alpha version...
*** This bug has been marked as a duplicate of 205137 ***
I really doubt this is the same thing that 5137. 5137 is a wishlist, while this one is actually a bug. If the time is displayed as "06:58" no matter if it's AM or PM, then there's no way for the user to know if it's morning or afternoon. It should be either "06:58 AM" and "06:58 PM", or "06:58" and "18:58". Also this happens specifically with the italian locale, while the other is a general request of more flexibility. There's also a Debian report for this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=281501
adding i18n keyword
its in 24 hour format for me, at least in 2.1 probably jsut a translation error.
Created attachment 45340 [details] This jpg shows the problem with italian locale I'm attaching a jpg that shows the screen of a 2.2.1 evolution, with the italian locale (it_IT.UTF8) and the bug is still there.
*** Bug 304426 has been marked as a duplicate of this bug. ***
Created attachment 46521 [details] how to get the date format from locale
bug 304426 suggests that evolution is trying to determine the date format from the .mo gettext translation file, but that will fail for any locales that you don't have a gettext translation for. You should use the setlocale() stuff for the date format since that doesn't depend on having translations present. (see previous attachment)
there's probably a good reason it's gotten from the translation files rather than the locale
Well, it would seem to be a good idea to fall back to getting the date format string from the locale if it isn't in a gettext translation file, since you don't seem to have translation files for every possible locale. en_NZ and it_IT locale users don't want to have screwed up dates.
translation files are specifically for this purpose. if the translation is out of date/non-existant then that is the problem with the translation. there is no way to know when you're "falling back", or if the string isn't in the gettext database. the locale date format string is no good because it isn't flexible enough.