GNOME Bugzilla – Bug 603488
LC_TIME not read?
Last modified: 2010-03-05 17:03:30 UTC
It would seem that LC_TIME is not taken into account for the display of the time in the top bar. [pcfe@x60-pcfe ~]$ date Tue Dec 1 16:40:02 EET 2009 [pcfe@x60-pcfe ~]$ env|grep LC LC_PAPER=fi_FI.UTF-8 LC_MONETARY=fi_FI.UTF-8 LC_NUMERIC=fi_FI.UTF-8 LC_DATE_TIME=en_IE.UTF-8 LC_MESSAGES=en_IE.UTF-8 LC_MEASUREMENT=fi_FI.UTF-8 LC_TIME=en_IE.UTF-8 LC_DATE=en_IE.UTF-8 yet in the top panel I see 'Tue 4:40' instead of 'Tue 16:40'. Mind you, no AM/PM, so at least that part it picked up from my variables. Am I DoingItWrong(tm)? If yes then how to do it correctly? If no, then it's a bug.
Created attachment 154782 [details] [review] patch to fix this issue trivial fix to improve the 12-vs-24 hour clock detection.
this fixes the issue for me; the current AM/PM check does not seem to work using my locale (and the bug reporter's), and this one does, at least for me.
Can you add some log() and figure out why the current check doesn't work? (To satisfy our curiousity at least)
Ok, some context first. I'm using ubuntu 9.10; I set my locale in my shell (even source that in my ~/,gnomerc). I'm using the en_DK locale, because I like the continental-European time/date format, but English language. The default locale on my system is en_US.UTF-8 Now, the critical difference here seems to be that if I set the language in gdm to 'English (Denmark)', things work as expected; however, when I leave it as 'unspecified', the problems that's fixed (or worked-around) by this patch occurs. It seems some kind of mix of locale settings is active then; look at the screenshot; the %p and %X checks are inconsistent. My date check seems to work a bit better in that case, even I don't fully comprehend what's going on. Also note that toLocaleFormat behaves the same in firefox.
Created attachment 154792 [details] screenshot showing the toLocaleFormat %X and %p
Hmm, weirdly en_IE and en_DK both give me unmixed cases - %X='15:27:25' %p='' But I do see some mixed cases in testing, among others: en_UK - %X='15:27:44' %p='PM' ja_JP - %X='15時28分06秒' %p='午後' And also in the other direction. hy_AM.utf8 %X='03:33:26 ' %p='' ms_MY.utf8 %X='03:33:28 EST' %p='' mt_MT.utf8 %X='03:33:28 EST' %p='' Guess if you speak Armenian, Malaysian or Maltese, or you just know if it's morning or afternoon :-)
Review of attachment 154782 [details] [review]: If you submit a new patch, can you do it by committing your patch using 'git commit' and then formatting the patch with 'git format-patch HEAD -1'? ::: panel.js.bak @@ +555,3 @@ } + // we check whether the current locale thinks 5pm starts with 17 + let fivepm= new Date(1267026359524); This isn't going to work - 1267026359524 isn't always 5pm - it depends on the timezone. What I think you want to do is to create a date (might as well create it just as the current date), then set the hour/minute/second explicitly @@ +556,3 @@ + // we check whether the current locale thinks 5pm starts with 17 + let fivepm= new Date(1267026359524); + let isTime24h = (fivepm.toLocaleFormat("%X").substr(0,2) == "17"); This doesn't quite work either. On my system, the one example where it breaks is: fa_IR.utf8 %X='۱۵:۳۹:۱۴' %p='' (There are some more examples of localized digits, and also of initial spaces in the time, or other leading characters, but they all happen to be 12hour locales) Sadly, grep'ing for %H inside %X doesn't work either for fa_IR, since for fa_IR, %H is '15'. But I think that approach (after setting the time explicitly to 15:00:00) is about as good as you can get.
It's also worth noting that bug 600276 proposes replacing the am/pm automagic with a gconf key (think gnome-panel here) - the default value should depend on the locale [1], but users are still able to adjust it if the default doesn't fit. [1] currently it doesn't, but that's easily fixable by enabling intltool-magic for the schema file
Created attachment 154811 [details] [review] updated patch to improve 12/24 hour clock detection this patch does not only work in my timezone anymore (a nice 24x improvement); it might even work in the locales that don't use arabic numbers.
As an added datapoint here, I live in the UK and use English as my main language. But having grown up outside the UK I still prefer the 24H clock and metric measuring, so at least for my usecase the automagic stuff is probably destined to not get it right.
(In reply to comment #10) You can of course use en_DK.UTF-8 for LC_TIME to get an english-language yet 24h clock. Or you can roll your own. Anyway, the LC_* stuff might not be the best solution anyway, and we might simply have a configuration setting for the clock, as there is for the Gnome2 panel clock. Until then, this patch may be useful.
Yes this isn't the right solution, i use en_PT locale on all my machines and i'm on Portugal timezone (UTC) so the best is to set a configuration like on gnome-panel.
Review of attachment 154811 [details] [review]: I went ahead and fixed up style for this patch and pushed. Thanks for the patch! ::: js/ui/panel.js @@ +558,3 @@ + // start with the same 2 digits, it must be a 24h clock + // if the locale representations of 05:00 and 17:00 do not + We don't have much code that does multiple statements per line.