User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20060426 Firefox/126.96.36.199 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060507 Mozilla Sunbird/0.3a2 Regardless of what you choose for the timezone preference from the options tab, the event dialog creates an event in terms of the OS timezone. This can be a little confusing. Reproducible: Always Steps to Reproduce: 1. Set OS to Central time, America/Chicago 2. Start Sunbird 3. Go to Options->Timezone Change timezone from America/Cancun to America/Phoenix 4. Create an Event on 5/22/2006 at 4PM in the Event dialog 5. When you click OK, the event is saved to the calendar on 5/22/2006 at 2PM. If you check timeanddate.com you can see that on 5/22/2006 4PM Central Time == 5/22/2006 2PM Phoenix time. Actual Results: Therefore, the event dialog is creating the events in terms of the original OS timezone. This can be further verified by leaving the timezone preference set to America/Phoenix and closing sunbird. Change your OS timezone to America/New York, start sunbird again, and try the test case. Note that the event dialog now interprets your entry as though it is in New York time, and converts it to Phoenix time in the views (i.e. the same test case above will cause an event on 5/22/2006 at 1PM to show up on the view). Expected Results: The event dialog should create events with regard to the user's current timezone preference. For all verification on this defect, I used the month view for display, and timeanddate.com to double check the timezone calculations. Although this can be fixed by allowing the user the option to pick the timezone of an event from within the Event Dialog, I think that even that timezone picker should default to whatever Timezone preference setting the user has currently selected in the options panel.
I think this is a duplicate of Bug 332868 / Bug 296659. The dialog uses calIDateTime.jsDate for displaying the times. But jsDate can't handle timezones properly. Therefore the offset.
(In reply to comment #1) I agree that the issue is definitely occuring because of jsDate's timezone issues. However, there is also a UI component to this as well: when the dependency on jsDate is removed, the event dialog must make certain to adhere to the user's timezone preference selection. So, yes, it is something of a duplicate, but perhaps not entirely.
Clint, is this the same as the new Bug 349812? (That new bug already have patch)
(In reply to comment #3) > Clint, is this the same as the new Bug 349812? (That new bug already have > patch) > Stefan, I think they are the same. I'll make this one a dup of Bug 349812 *** This bug has been marked as a duplicate of 349812 ***
(In reply to comment #4) > *** This bug has been marked as a duplicate of 349812 *** > Note that bug 349812 only applies to tasks, is it still really a dupe?
Reopen bug. The issue still exists in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070118 Calendar/0.6a1. The time picker in the Event/Task dialog always displays the time in OS timezone; while the calendar view, tooltips, unifinder and task list display the time in the timezone that is set in preferences. If both timezones doesn't match different times will be displayed or the event is created on a different time than displayed in dialog respectively. Since time picker is the only one that uses jsDate Bug 296659 and Bug 328442 might help us here.
Stefan, in 30 minutes you have found 3 duplicates, wow! I wonder how are you about this bug because of two others that are depend on this issue. Should be fixed before next release 0.5?
This means things get screwy if the system's timezone and the app's timezone aren't set the same, and don't match in content. :(
This bug, plus guessSystemTimezone guessing the wrong timezone, is causing bug 363121. We'll need a big relnote for 0.3.1 saying "Be sure to set your timezone"
Matthew, even if OS and Calendar timezone settings match, daylight savings time can still screw it up. I think every view or dialog in Calendar should use the same setting. IMHO, better if Calendar used only OS time, and timezone shift be an option. Sad I'm not a programmer, this seems easy to solve. Best regards
(In reply to comment #14) > I think every view or dialog in Calendar should use the same setting. IMHO, > better if Calendar used only OS time, and timezone shift be an option. Sad I'm > not a programmer, this seems easy to solve. I think all calender-views should use OS-time too, but dialogs should use the preference TZ (like ctalbert says). Best would be if the event-dialog would have a field for the TZ at the bottom as this is not often used. As an intermediate, partial, solution the edit-event dialog could have a text showing the TZ the event is in when OS and SB timezones don't match. But the events in calendar-views should be recalculated based on OS-timezone. This way when one is travelling, assuming one sets OS-time to the place one is in, one will never be late or early... This could also be an option: show timezones in events.
Having fought with tz issues in another environment for a long time, I wanted to suggest something. These might be idealistic, but here goes. 1) Gecko-based stuff should be able to have its own tzdata, but there should be explicit preference to allow user to specify whether to use the OS or the app tz data. 2) The user should be able, in the UI, to create an event in another time zone without changing their tz, or their own view of their current time zone. 3) The user should _always_ see the time zone for an event they have created, in textual representations of the event. Really, people should realize they are always in a time zone. It is not too much information. 4) The directory location of app-specific tz data should not be hard-coded.
This will require reworking the datepicker to not use jsDate. We won't block 0.5 on this.
I'm not sure this is the same problem, but on a MacPro (OS X 10.10) I just installed Eudora and Lightning. My rtime zones in the OS and Calendar are both EDT. But my alarms seem to display 6 hours early in GMT! This makes the calendar neigh-on to useless.
I have Lightning .5 by the way...
Hi. Is this being solved for 0.7? I know it's maybe too late to raise any question on 0.7, but it could be a chance to get rid of this. If not, may I suggest 0.9 as a milestone? I'd suggest that, in Calendar Timezone settings, an option "Use OS setting" was included and, better, default. This way, a beginner would never have to worry (I don't use alternate tz myself), and an advanced user, which wanted to mess with tz, could have his way too. Many thanks, Emerson
Fixed with bug 328442? We need to resolve these bugs for 0.8 => wanted-0.8.
This seems to be gone in Lightning 0.7 for me in OS X
Clint, could you please verify whether this bug has been fixed with the fix of bug 328442?
With the case in comment 0 : OS set to central time, lightning set to phoenix time I created an event from 9.00 to 11.00 (at phoenix-time). It did show up in my calendar at 9.00 to 11.00. Also after setting the OS-timezone to New York, the event stays from 9.00 to 11.00 in the view. So this bug is solved in lightning 0.8pre (2007111604) and Sunbird 0.8pre (20071123) To be honest, I don't see the usercase where the timezone in Lightning may differ from that of the OS, except for creating multiple events in a different timezone the user is in now. I think we can assume the OS-timezone is the timezone the user is currently in all the time (see comment 17). But this bug may be marked fixed by bug 328442 as the picker does behave like it should and the behaviour is as Clint described.
Fixed with bug 328442 per comment #29.
In reply to the 2nd part of Comment #29: pls see my Comment #14. Even if OS and Lightning are set to the same tz, there is an issue with savings time. Unfortunately, all Windows machines enter and leave daylight savings time in the wrong days in Brasil. It's intrinsic about how Windoze handles daylight savings dates, so no solutions in the OS side are plausible. Dunno about other OSs. Well, it's not a Calendar problem, rather an Windows one. But I'm glad about this is fixed, because it solves eventual problems with miscalculated time around. Thanks.