Closed
Bug 380285
Opened 17 years ago
Closed 16 years ago
Day/Week/Month views show incorrect start time for events
Categories
(Calendar :: Calendar Frontend, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: mozilla.org-eolg, Unassigned)
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 Build Identifier: Thunderbird version 2.0.0.0 (20070326) On XP/SP2. OS timezone set to "(GMT) Greenwich Mean Time: Dublin, Edinburgh, Lisbon, London" and "Automatically adjust clock for DST changes" is set. Lightening timezone set to "/mozilla.org/20070129_1/Europe/Dublin". If I create an event and enter a time then the time displayed in the calendar is one hour after the start time selected. If I double-click on the event, the edit dialog contains the correct time. Reproducible: Always Steps to Reproduce: 1. Set timezones as above. 2. Create an event. Actual Results: Time displayed in calendar is +1 hour. Expected Results: Time displayed in calendar is same as time entered. Possibly related to bug 337191
Reporter | ||
Updated•17 years ago
|
Version: unspecified → Lightning 0.3.1
Comment 1•17 years ago
|
||
This is a duplicate of bug 337191. At the moment your OS timezone and the timezone selected in Lightning must match to get correctly displayed times in views and event dialog.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 2•17 years ago
|
||
As far as I can tell, they do match. The OS timezone is set to "(GMT) Greenwich Mean Time: Dublin, Edinburgh, Lisbon, London". The Lightning timezone is set to "/mozilla.org/20070129_1/Europe/Dublin" I can't see any alternative in Lightning or Windows to give a better match...
Comment 3•17 years ago
|
||
Sorry, I didn't read your report carefully enough. Have you restarted Lightning after changing your timezone? Can you attach an export of a single incorrect displayed event as ICS file to this bug? Does the bug only occur for repeating events, maybe a repeating event defined for a timespan crossing the DST boundary?
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Reporter | ||
Comment 4•17 years ago
|
||
Contains a test event. See also related screenshot.
Reporter | ||
Comment 5•17 years ago
|
||
Reporter | ||
Comment 6•17 years ago
|
||
See attached * test-calendar.ics * screenshot.png - shows the task and the edit dialog
Reporter | ||
Comment 7•17 years ago
|
||
Forgot to mention - this occurs for all events (repeating and non-repeating), regardless of start time & timespan. I have restarted Lightening (Thunderbird).
Comment 8•17 years ago
|
||
What is your Windows setting for "Automatically Adjust Clock for Daylight Savings Changes"? Does Lightning behaves correct if you change this setting? From looking at the .ics file and the screenshot it is clear that the views display the event at the correct time and the time in the dialog is wrong: DTSTART;TZID=/mozilla.org/20070129_1/Europe/Dublin:20070511T090000
Reporter | ||
Comment 9•17 years ago
|
||
"Adjust Clock" was set. I tried unsetting it and restarted Thunderbird. My system clock went back an hour but it had no effect on the behaviour of Lightning - events are still displayed an hour after the time shown in the edit dialog.
Comment 10•17 years ago
|
||
My times are off by 2 hours. I enter 18:00 and it shows 8:00PM. Am I having the same problem.
Comment 11•17 years ago
|
||
Ed and Jeremy, could you check with the latest nightly builds of Lightning and see it this is still happening? The dialog has been changed and I think this is solved with bug 328442..
Comment 12•16 years ago
|
||
This is still a problem in Sunbird 0.3, except that I'm seeing time scheduled events/reminders as 1 hour earlier in all calendar display windows. When the event is opened to the event entry window the scheduled times are correct, but they show up in Calendar and pop-up info boxes as 1 hour earlier. This appears to be an issue around the recent uncertainty in Daylight Savings Time change dates and doesn't affect after that window of uncertainty.
Comment 13•16 years ago
|
||
This has been fixed in current 0.8 release candidate builds. Please reopen if you see it in *current* (0.3 has not been current anymore for since 1,5 years) builds.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago → 16 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•