Closed Bug 266241 Opened 16 years ago Closed 13 years ago

want AM/PM everywhere, not 24-hour time

Categories

(Calendar :: Calendar Views, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jwz, Unassigned)

References

Details

Attachments

(1 file)

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
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.
> 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.)
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.
(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.
This may be a consistency issue more than a preference issue.  See bug 260571
comment 2.
>   - 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
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
QA Contact: gurganbl → sunbird
A choice is better not only am pm since i use 24 hour myself
Was there ever a fix on this?
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).
Attachment #214851 - Flags: first-review?(mvl)
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.
Attachment #214851 - Flags: first-review?(mvl) → first-review-
(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 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
Attachment #214851 - Flags: first-review- → first-review+
Attachment #214851 - Attachment description: use local time format in new views → use local time format in new views [checked in]
*** Bug 331766 has been marked as a duplicate of this bug. ***
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.
Fix for the Lightning regression has been checked in with r=jminta from irc.
*** Bug 328284 has been marked as a duplicate of this bug. ***
Is there a reason this bug remains open?
Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
(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.
Status: NEW → RESOLVED
Closed: 13 years ago
Component: Sunbird Only → Calendar Views
OS: Linux → All
QA Contact: sunbird → views
Hardware: PC → All
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.