Closed
Bug 363121
Opened 19 years ago
Closed 19 years ago
events in the week of daylight savings shifts events are 1 hour off
Categories
(Calendar :: Calendar Frontend, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: phatpenguin, Unassigned)
References
Details
Attachments
(1 file)
|
2.81 KB,
text/calendar
|
Details |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.3) Gecko/20060425 SUSE/1.5.0.3-7 Firefox/1.5.0.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061006 Sunbird/0.3
In the last week of October daylight savings time ends..in the last week of march it begins (Sunday of each week)
durring those weeks all events are off by one hour. Reoccuring events shift by one hour if you chose to look at the one instance of the event and non reoccuring events just show up an hour off
Reproducible: Always
Steps to Reproduce:
1. Create a new event with a specific time in the last week of March or October
2. create a re-occuring event from the first week reoccuring weekly.
Actual Results:
The reoccuring event looks fine, but opening this occurance only.
The stand alone event is 1 hour earlier.
Expected Results:
View should match the event details.
also reproduced on sunbird/0.3 for windows.
Using America/Boise timezone.
I have a variation on the theme: The rest of the month after Daylight Savings time begins, all new events are shown 1 hour early. Should this be a different bug?
Thunderbird version 1.5.0.9 (20061206)
Lightning 0.3
NB: in 2007, DST begins 11 Mar... Using America/Toronto timezone.
Steps are similar: Add a new one-time event on any day from March 11 through March 31 (inclusive, hereafter referred as the "problem period") and the add dialog box shows the right time. After clicking OK, it is displayed in the calendar view and tooltip incorrectly: times are 1 hour EARLY (ie. a 7 PM time appears as a 6 PM time in the main display and tooltip). This affects Day, Week and Month views. Editing the event produces the correct times in the edit dialog.
Recurring events are unaffected if they start BEFORE DST does. However, if the recurring event begins in the problem period, ALL instances of the recurring event are incorrect -- even if they flow out of the problem period...
Expected result is the same: View and tooltip should match event details in the edit dialog during the problem period.
Comment 2•19 years ago
|
||
(In reply to comment #0)
> Using America/Boise timezone.
Bug 321653 handles importing of new timezones, which will have the new 2007 US daylight saving rules. Once that lands on 0.3.1, your issue should go away.
Updated•19 years ago
|
Flags: blocking-calendar0.3.1+
Updated•19 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #2)
> (In reply to comment #0)
> > Using America/Boise timezone.
>
> Bug 321653 handles importing of new timezones, which will have the new 2007 US
> daylight saving rules. Once that lands on 0.3.1, your issue should go away.
>
I have checked this bug on 0.3.1 Sunbird (Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;en-US;rv1.9a1) Gecko/20070130 Calendar/0.3.1pre) BuildID: 2007013013.
This has today's 0.3.1 timezone fixes in it. And yet, when I first start Sunbird I can reproduce this problem following these steps (I am in America/Chicago timezone, which Sunbird by default guesses to be America/Cancun).
1. Start Sunbird with a clean profile
2. Make an event starting at 01:00 on March 11 (before DST shift)
3. Event in view is listed as 01:00
4. Make an event starting on March 11 at 04:00 (afterof DST shift) and event in view is listed as 03:00. (you can also make any event between March 11 and April 1 and see the shift).
5. On April 1, create an event at 20:00 and it will be listed as 20:00 in the view.
You can do the same thing starting on October 28 and going to November 4.
The work around:
1. Start Sunbird in a clean profile
2. Set your timezone preference up front
3. Restart sunbird
4. Check the steps above - the event will always be listed in the view at the same time that you selected in the event dialog.
And now for the wierd part:
According to http://www.timeanddate.com/worldclock/results.html?query=cancun
* America/Cancun shifts into Daylight time on April 1, not March 11.
* America/Cancun shifts out of Daylight time on October 28.
Compare that to my actual timezone (and machine zone) of America/Chicago, which in 2007 (with the new rules):
* Shifts into Daylight time on March 11
* Shifts out of Daylight time on November 4.
Maybe coincidence, maybe indicative of other issues beneath the surface. I don't know.
The other odd thing: This does not seem to be reproducible on windows. It is reproducible on Linux and Mac.
After much debugging and discussion we have determined that this is actually the same issue as 337191. Marking as a dupe.
Status: NEW → RESOLVED
Closed: 19 years ago
Flags: blocking-calendar0.3.1+
Resolution: --- → DUPLICATE
Reopening. Okay...After *even more* debugging and discussion we have gotten to the bottom of this issue.
This is actually a behavior manifested by two bugs, working together:
Bug 328996 - guess system timezone guesses the wrong timezone
Bug 337191 - event dialog datepicker always uses OS timezone and not application timezone.
If your machine is set to America/Chicago (American Central Time), then when you start up Lightning/Sunbird it will incorrectly guess your timezone to be America/Cancun.
Note that in 2007 America/Chicago will shift into DST on March 11.
Note that in 2007 America/Cancun will shift into DST on April 1.
When open the event dialog to create an event at 19:00 March 12, 2007, the Event Dialog uses the machine timezone of America/Chicago to translate this to UTC as March 13, 00:00. (adds a 5 hour offset to get UTC).
Now, when the event dialog closes, the views take that time and call calDateTime::getInTimezone (http://lxr.mozilla.org/seamonkey/source/calendar/base/src/calDateTime.cpp#345). This calls down into libical which tries to convert this time from UTC to your current APPLICATION timezone of America/Cancun. Since Cancun does not shift into DST until April 1, 2007, it uses a -6 offset to convert it from UTC to America/Cancun. And thus the view will display the event as 18:00 March 12.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 6•19 years ago
|
||
This is a major problem imho as who don't have a locale-version of sunbird will use en-US. My OS is windows-nl and the en-US locale shifts the events on 11-3, 24-3, 24-4, 30-9 and 31-10. Using the nl-locale of sunbird and after applying the update 0.3.1rc2 everything looks allright.
Comment 7•19 years ago
|
||
This calendar has non-recurring events through March 2007. In Lightning 0.3.1, events after the daylight saving shift in the US are displayed an hour late.
Comment 8•19 years ago
|
||
I just updated to Lightning 0.3.1, and am now seeing non-recurring events off by an hour in March after the daylight saving shift. I have attached a sample file created by an external program (amion.com) showing events for the month of March. Before the daylight saving shift, the events are timed correctly. After the shift, all events display an hour late.
My configuration:
WinXP, Thunderbird 1.5.0.9, Lightning 0.3.1, machine and calendar timezones: America/New_York.
Sample file attached with previous comment.
Comment 9•19 years ago
|
||
Have you installed the updated timezone patch from Microsoft?
Comment 10•19 years ago
|
||
Michael - I had the same issue. It turns out the problem was that I'd lost an XP setting. Go to Control Panel, Date & Time, Time Zone. Be sure that "Automatically adjust clock for daylight savings changes" is checked (mine was unchecked). Then restart Thunderbird.
You'll have to re-create those events that were mis-timed.
As an aside, the Thunderbird restart appears to be necessary. I assume that means Lightning queries the OS timezone only at Lightning's invocation.
Comment 11•19 years ago
|
||
If someone can try to reproduce this with and without the MS timezone patch I'd love to hear the outcome.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Keywords: qawanted
Resolution: --- → FIXED
Comment 12•19 years ago
|
||
I am up-to-date on all Microsoft patches, so I don't think it has anything to do with my XP settings. Moreover, I have reproduced the bug in Sunbird 0.3.1 on a Win2000 (SP4) machine with the time-zone patch applied (using the file attached above). The "automatically adjust clock" option is/was selected. The problem may have something to do with the calendar file itself, as it was generated by a third-party application (amion.com), but I don't know anything about the .ics format def., so I don't really know.
Comment 13•19 years ago
|
||
(In reply to comment #12)
> I have reproduced the bug in Sunbird > 0.3.1 on a Win2000 (SP4)
> machine with the time-zone patch applied (using the > file
> attached above).
How did you updated the timezone rules in Windows 2000? Microsoft only provides a patch for Windows XP and higher. For older systems you have to hack the registry manually.
Comment 14•19 years ago
|
||
(In reply to comment #12)
I have verified that your ICS displays properly on my both my Windows XP and Mac using Sunbird 0.3.1 and Lightning 0.3.1 with Tbird 2b2 and Tbird 1.5.9. I don't think this is an issue with the 0.3.1 code.
One thing to be certain to check is that Lightning/Sunbird has guessed your timezone properly. It will sometimes guess incorrectly, and so you will have to manually set the timezone via Tools->Options dialog, timezone tab (Lightning panel, timezone tab in Lightning). After setting the timezone, you must restart the application. If the calendar happened to choose an incorrect timezone (one with different DST rules) then you could see this issue.
Another possible issue here is that your ICS file is a little inaccurate. All the times are stored in UTC, so if you were verifying this by calculating a difference between the timezone you entered the times in and the timezone that you are displaying them in, then there could be an issue there (sometimes such calculations lose the DST information).
Also, you might want to take a look at your third party tool, because the events that it is generating do not match the event summaries that were entered. While this has nothing to do with timezone offsets, it would spell disaster if you were trying to schedule items with it.
An example: The event "Event 10p-7a" (UID:OnCall++3724++127) that occurs on March 14, claims to be from 10PM to 7AM in your title, but it is actually only 59 minutes long, if you look at the ICS definition (from 0400Z to 0459Z). Likewise "Event 10p-7a (Cont'd)" on March 14 (UID:OnCall++3725++127) only has a duration of 7 hours, not 9 hours, as the title might lead you to believe.
I'm not sure what issue you are seeing. You might check to see what timezone lightning is actually using by going to Tools->Options, advanced tab, Config Editor. Type "calendar.timezone.local" into the "Filter" textbox at the top and hit enter. This will show you the actual timezone that Lightning has set. You can change this using the normal timezone picker on the Lighting->timezone panel and then restart Thunderbird to have it take effect.
You need to log in
before you can comment on or make changes to this bug.
Description
•