If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Display of date/time of absolute reminder is confusing (switches between UTC and local time)

VERIFIED FIXED in 1.0b1

Status

Calendar
Alarms
VERIFIED FIXED
9 years ago
6 years ago

People

(Reporter: Stefan Sitter, Assigned: Fallen)

Tracking

Bug Flags:
blocking-calendar1.0 +

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
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

9 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

9 years ago
Created attachment 371067 [details] [diff] [review]
Fix - v1

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.
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #371067 - Flags: review?(ssitter)
OS: Windows XP → All
Hardware: x86 → All
(Reporter)

Comment 3

9 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

9 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
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
(Reporter)

Comment 5

8 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

6 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.