Open Bug 399851 Opened 17 years ago Updated 2 years ago

Setting / detection for 12/24 hour clock display needed

Categories

(Calendar :: General, defect)

x86
All
defect

Tracking

(Not tracked)

People

(Reporter: mozilla.org, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20061201 Firefox/2.0.0.6 (Ubuntu-feisty)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8pre) Gecko/20071002

All time strings in my calendar show up as AM/PM, even though the graphical clock is set to display 24 hours (running Ubuntu Feisty Fawn), and my time zone is set to "/mozilla.org/20070129_1/Europe/Zurich", where default display is 24 hours.

Reproducible: Always




Strangely, date and hwclock display differently:

$ date
Mon Oct 15 13:44:58 CEST 2007

$ hwclock 
Mon 15 Oct 2007 01:45:48 PM CEST  -0.467712 seconds

No LC_ variables are set:

$ set | grep LC_
[nothing displayed]
I think it's a duplicate of bug 298354
Bug 298354 is a composite report with very little detail. As noted there, should it be split into separate reports?
Hello. I am experiencing the same issue as Victor Engmark in Ubuntu Hardy with Lightning 0.8.

I am running a english install of Ubuntu, with my location set to Sweden (we use 24 hour time). Also in the Gnome settings, i have configured to display 24 hour time.

But Thunderbird 2.0.0.14 & Lightning is still displaying 12 hour AM/PM times, which makes me believe this is rather a bug in Thunderbird than in Lightning?

I am also using Lightning 0.8 in Windows, where 24-hour time is displayed correctly.
Imho, having gui switches, or at least about:config switches, to toggle 12/24 hr formats and US/European/ISO date formats (ie, not always mm/dd/yyyy, but also dd.mm.yyyy or yyyy-mm-dd (strftime(3) string values?)) would be really a good thing, and much better than putting efforts into some auto-detection routine that are bound to annoy someone anyway.

Just my 0.02 cents...
+1 for having a setting, though in bug 351459 it was decided not to fix this. This question has been asked a lot of times in the forums and there's quite some bugs already. I suggested picking this one as the main bug and dupe bug 298354 and bug 271162. It will also make bug 359083 easier for HB, will make bug 255668 easier to fix imho and perhaps also bug 290443. As this is a valid request confirming the bug. How do we go about with the semicolons, dots and slashes for the time/date-format?
Status: UNCONFIRMED → NEW
Ever confirmed: true
If you allow strftime(3) strings, the date and time display can become quite complex, and it's then the responsibility of the user to write the correct date format string into the preference. A notice to the user (in the online help?) about how to accomplish common displays for those who have a problem looking the man page up (eg. Windows users) would probably be good enough.
Keywords: helpwanted
OS: Linux → All
I am on Lighting 1.0b2 and still see this problem.

When creating events the times are shown in 24 hour format, i.e. 0 to 23 but on the event dialog and in the calendar they are shown as am/pm times.
I am on Lighting 1.0rc1 under Thunderbird 8 beta and this is still an issue. No change from Mr. Bruhin's prior comment:

In the 'Edit Event' windows,  times are shown in 24 hour format with no way  to change how the time is displayed. All other dialogs I've run into thus far show up as "normal" am/pm times.
Here, Lightning-1.3 on SeaMonkey-2.8 (Gentoo build):

$ date
Tue Apr 24 17:44:41 CEST 2012
$ locale
LANG=en_US.UTF-8
...
LC_TIME=en_DK.UTF-8

Still, in event window, the clock menu brings up a 24h dialog (correct), but then displays AM/PM -- annoying.
I really prefer 24h times, as the AM/PM split drives me ...d'oh... nuts (I'm possibly allergic ;-)). Please, please, gimme an option to configure; suggested:

  calendar.time.format <integer> [0,1]
    0 := 24h (default ;-))
    1 := AM/PM

Cheers,

  ^m'e
Just discovered a possibly related Bug 379279. Indeed, as for my 12/24h display, I can work around it by resetting LANG, i.e.

$ export LANG=; seamonkey

...enjoy :-)
Any update on this?
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.