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.
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+
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)
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+
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: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
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
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.