GNOME Bugzilla – Bug 580945
Clock should be configurable
Last modified: 2010-05-09 01:14:47 UTC
In my country we use 24 hour time format, but the clock ignores the locale settings and it shows 12h time format and it's without any AM/PM flags.
I'm seeing this issue as well
Created attachment 140298 [details] [review] Bug 580945 - Have clock respect 12/24 hour clock panel prefs Load the panel prefs; realistically we depend on gnome-panel installed for a non-composited fallback.
Here the key is called /apps/panel/applets/clock_screen0 instead of /apps/panel/applets/clock, so this has no visible effect. Looks good to me otherwise, except that «this._customFormatKey = this._customFormatKey + '/custom_format';x should probably be «this._customFormatKey = this._formatKey + '/custom_format';», and that maybe it should connect to that key too.
I think the problem with the clock GConf configuration being special with the schema bound to some directory is pretty fundamental. That is, relying on gnome-panel being installed is OK(-ish) but relying on the user having run gnome-panel and gnome-panel having done magic to bind the clock applet schema into the applets/ subdir isn't. We could use: dgettext("gnome-panel", "24-hour"); to get the default value for the current locale, once the gettext module in gjs lands. Or once the gettext module in gjs lands we could just add our own translatable key for this and avoid the gnome-panel dependency.
Commit ca51a8c926be8e0c268ba3d87dcde5411df630f2 fixes this bug by just marking the clock format as translatable.
Created attachment 146430 [details] [review] Makes the clock format configurable This patch to current master implements changing the clock format with a GConf key "clock/format". The idea is for the config app to change this key. The patch needs a bit of work (at least take out the magic string "clock/format") and could be merged into the other proposed patch. This is in order not to depend on the gnome-panel clock applet to set the format for us.
Created attachment 147135 [details] [review] Detect whether the clock should be displayed in 12h or 24h format This patch 'detects' whether the clock should be displayed in 12h or 24h format by looking at the am/pm string: if it's empty display a 24h clock. AFAIK the gnome-panel clock uses the same trick. Note that making the time format translatable may not be sufficient: this time format bound to LC_MESSAGES, while it really depends on LC_TIME. For example, I have set LC_MESSAGES to 'en', but LC_TIME to 'de', and I'd expect time to displayed in 24h format (as customary in the 'de' locale), not 12h (as it would be in the 'en' locale).
(In reply to comment #7) > 12h (as it would be in the 'en' locale). That would depend on which “en” you mean: en-GB should be 24-hour; perhaps en-US and some others would be 12-hour.
Well, even in es_ES, some people use 12-hour and some use 24-hour clocks. What is being done is fine as a sane default, but we still need a way to configure the clock (I want to have the day of the month, for example). Is there some sort of general concensus on how this should be made? And BTW, on the calendar, Sunday still comes out as the first day of the week, instead of Monday (as mandated by my LC_TIME=es_ES.UTF-8 locale.
FWIW, I got a patch from a Debian user in a bug report, as well, though I think you guys have got what it does covered already: http://bugs.debian.org/558198
Review of attachment 147135 [details] [review]: Sorry about this patch falling through the cracks! I think we want this configurable in some way in the future via GConf but for now this patch looks like a decent incremental fix.
Retitling this bug, I think consensus was we wanted a way to make the clock configurable in general via GConf.
Comment on attachment 147135 [details] [review] Detect whether the clock should be displayed in 12h or 24h format Attachment 147135 [details] was pushed a while ago as c21e692652a95.
(In reply to comment #12) > Retitling this bug, I think consensus was we wanted a way to make the clock > configurable in general via GConf. Fixed in master. *** This bug has been marked as a duplicate of bug 600276 ***