266241 - want AM/PM everywhere, not 24-hour time

Status: RESOLVED FIXED

(Calendar :: Calendar Frontend, defect)

Description

[Jamie Zawinski]

I think in AM/PM, not in 24-hour time.  The calendar likes to use 24-hour time
everywhere.  I would like an option to get everything to use 12-hour time
instead, including at least:

   - row headings in Day View
   - row headings in Week View
   - event boxes in Multiweek View and Month View
   - Start/End fields in Edit Event

Calendar 2004092412
Mozilla 1.7.3
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922

Comment 1

[gekacheka]

Mozilla uses the operating system date and time formats so they are consistent
across the screen.

For windows, the FAQ explains how to change the date format, the time format is
similar (in Start | Settings | Control Panels | Regional Options, select Time
tab instead of Date tab).
http://www.mozilla.org/projects/calendar/faq.html#date_format  

For Linux desktops, we need a FAQ answer (and eventually put it in
documentation).  A start is at bug 263329 comment 3.

Comment 2

[Jamie Zawinski]

> For Linux desktops, we need a FAQ answer (and eventually put it in
> documentation).  A start is at bug 263329 comment 3.

I'm using Linux.  Maybe I'm missing something, but I don't see a way to set
$LC_TIME such that I get "31 Oct 2004": I think that only lets me choose between
"31/10/2004", "10/31/2004", and "2004/10/31".

I suspect that to make this work, you're going to need to add a preference to
Calendar; I don't think that Linux *has* system-wide preferences for
presentation like this (there don't even seem to be Gnome-specific ones, from
what I can tell.)

Comment 3

[Jamie Zawinski]

Oh, wait, I'm sorry, I got confused and thought this was bug 266243, not bug
266241 (you were talking about AM/PM, not about month format.)

Anyway, I think the same thing is true of both.

I see that the Gnome Evolution calendar has a preference for 12/24 hour time. 
That strongly suggests that there's no more global preference for that, or they
would have put it in Control Center instead of in the application itself.

Comment 4

[Rob]

(In reply to comment #1)
> Mozilla uses the operating system date and time formats so they are consistent
> across the screen.

I don't think formatting is the problem here.  When viewing calendars, I see
AM/PM format but when editing an event I have to choose among 24 hours.  And try
as I might, I don't see any option to set events with AM/PM time instead of
24-hour time.

Comment 5

[Richard Greenwood]

This may be a consistency issue more than a preference issue.  See bug 260571
comment 2.

Comment 6

[Jamie Zawinski]

>   - row headings in Day View
>   - row headings in Week View
>   - event boxes in Multiweek View and Month View

All of the above seem to be fixed in Sunbird 0.2.

>   - Start/End fields in Edit Event

This one is not fixed, but is also described by bug 260571.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20050203 Mozilla Sunbird/0.2

Comment 7

[Will Dimmit]

24 Hour time is also used when a selected appointments are printed.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20050203 Mozilla
Sunbird/0.2

Comment 8

[rb1888]

A choice is better not only am pm since i use 24 hour myself

Comment 9

[K. Druff]

Was there ever a fix on this?

Comment 10

[Stefan Sitter [:ssitter]]

Attachment: use local time format in new views [checked in]

This patch makes us use local time format in day/week view (timebar and drag'n'drop labels) and in multiweek/month view (event box).

Comment 11

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 214851 [details] [diff] [review]
use local time format in new views [checked in]

>Index: mozilla/calendar/base/content/calendar-multiday-view.xml
>+          var formatter = Components.classes["@mozilla.org/intl/scriptabledateformat;1"]
>+                                    .getService(nsIScriptableDateFormat);

We should be useing calIDateTimeFormatter everywhere. If you need nsIScriptableDateFormat, that means that calIDateTimeFormatter misses some functionality, and we should fix that. This workaround is just too hacky.

Comment 12

[Stefan Sitter [:ssitter]]

(In reply to comment #11)
> (From update of attachment 214851 [details] [diff] [review] [edit])
> >Index: mozilla/calendar/base/content/calendar-multiday-view.xml
> >+          var formatter = Components.classes["@mozilla.org/intl/scriptabledateformat;1"]
> >+                                    .getService(nsIScriptableDateFormat);
> 
> We should be useing calIDateTimeFormatter everywhere. If you need
> nsIScriptableDateFormat, that means that calIDateTimeFormatter misses some
> functionality, and we should fix that. This workaround is just too hacky.

Why hack? Why workaround? We have an integer value (theHour) and that should be converted to a time string. This code does this with the minimal effort.

For your proposal we would have to create a new calIDateTime object, then set all fields to zero, than set the hour, then call calIDateTimeFormatter that calls nsIScriptableDateFormat in the end too - that seems unnecessary and more resource consuming to me.

Comment 13

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 214851 [details] [diff] [review]
use local time format in new views [checked in]

Ok, i didn't read carefull enough. Sorry about that. I still worry a bit about using two different date formatted (because of prefs etc), but for now, this looks like the best  option.
r=mvl

Comment 14

[Stefan Sitter [:ssitter]]

*** Bug 331766 has been marked as a duplicate of this bug. ***

Comment 15

[Joey Minta]

Comment on attachment 214851 [details] [diff] [review]
use local time format in new views [checked in]

+          var formatter = Components.classes["@mozilla.org/intl/scriptabledateformat;1"]
+                                    .getService(nsIScriptableDateFormat);
Boo for magic include reliance.  This only works in sunbird because dateUtils.js is in the same context as the view xml.  Otherwise, nsIScriptableDateFormat isn't defined.  Lightning is therefore broken.

Comment 16

[Dan Mosedale (:dmosedale, :dmose)]

Fix for the Lightning regression has been checked in with r=jminta from irc.

Comment 17

[Joey Minta]

*** Bug 328284 has been marked as a duplicate of this bug. ***

Comment 18

[Matthew (lilmatt) Willis]

Is there a reason this bug remains open?

Comment 19

[Matthew (lilmatt) Willis]

Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove

Comment 20

[Stefan Sitter [:ssitter]]

(In reply to comment #18)
> Is there a reason this bug remains open?

The only remaining issue I see is the time picker -> Bug 255668.
Therefore I'm resolving this bug as FIXED.