Closed
Bug 486709
Opened 15 years ago
Closed 15 years ago
Display of date/time of absolute reminder is confusing (switches between UTC and local time)
Categories
(Calendar :: Alarms, defect)
Calendar
Alarms
Tracking
(Not tracked)
VERIFIED
FIXED
1.0b1
People
(Reporter: ssitter, Assigned: Fallen)
Details
Attachments
(1 file)
1020 bytes,
patch
|
ssitter
:
review+
|
Details | Diff | Splinter Review |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090403 Calendar/1.0pre (BuildID: 20090403035251) Steps to Reproduce: =================== 1. Start Sunbird with clean profile 2. Start creating a new event 3. Add a custom reminder with absolute date/time, e.g. 08-Apr-2009 01:00 4. Save the event 5. Restart application 6. Open the event, check reminder settings, edit reminder settings Actual Results: =============== After creation absolute date/time of the custom reminder is shown in local time (08-Apr-2009 01:00) in the event dialog. After application restart and opening the event dialog it is shown in UTC (07-Apr-2009 23:00) instead. In the custom reminder dialog it is shown in UTC (07-Apr-2009 23:00) in the summary on top but in local time (08-Apr-2009 01:00) in the edit fields below. After pressing the TAB key several times the summary on top switches from UTC to local time (08-Apr-2009 01:00). Results are based on using timezone Europe/Berlin (UTC+2) for Sunbird and OS. This is confusing. Expected Results: ================== Always show absolute date/time of the custom reminder in local time.
Flags: wanted-calendar1.0?
Assignee | ||
Comment 1•15 years ago
|
||
I think we should fix this for 1.0 to keep the alarms feature stable and keep the number of duplicate bugs low.
Flags: wanted-calendar1.0? → blocking-calendar1.0+
Assignee | ||
Comment 2•15 years ago
|
||
This should fix the issue. We might want to add an optional timezone parameter to toString(), but I think at the moment this is not needed.
Updated•15 years ago
|
OS: Windows XP → All
Hardware: x86 → All
Reporter | ||
Comment 3•15 years ago
|
||
Comment on attachment 371067 [details] [diff] [review] Fix - v1 r=ssitter. This should work for now but I'm a little bit concerned about the additional costs of getInTimezone() on each toString() call.
Attachment #371067 -
Flags: review?(ssitter) → review+
Assignee | ||
Comment 4•15 years ago
|
||
The only alternative I can think of is either keeping the time also in the local timezone, but this means we need to have each calAlarm object observe local timezone changes. Also since toString() isn't called all that often, I think its ok this way. Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/a5a12627e813> -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
Reporter | ||
Comment 5•15 years ago
|
||
Verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090611 Calendar/1.0pre (BuildID: 20090611031611)
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 6•13 years ago
|
||
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
You need to log in
before you can comment on or make changes to this bug.
Description
•