Last Comment Bug 337191 - Event/Task Dialog always shows times in OS timezone regardless of timezone preferences
: Event/Task Dialog always shows times in OS timezone regardless of timezone pr...
Status: RESOLVED FIXED
: dataloss
Product: Calendar
Classification: Client Software
Component: Preferences (show other bugs)
: unspecified
: All All
: -- normal with 4 votes (vote)
: 0.8
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
: 364130 365152 365800 368269 370936 374556 374925 (view as bug list)
Depends on: 296659 328442
Blocks: 363121 400318
  Show dependency treegraph
 
Reported: 2006-05-08 14:39 PDT by cmtalbert
Modified: 2008-02-04 01:21 PST (History)
15 users (show)
dbo.moz: wanted‑calendar0.8+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description cmtalbert 2006-05-08 14:39:38 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
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.
Comment 1 Stefan Sitter 2006-05-09 02:45:38 PDT
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.
Comment 2 cmtalbert 2006-05-09 16:00:32 PDT
(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. 
Comment 3 Stefan Sitter 2006-08-26 13:58:12 PDT
Clint, is this the same as the new Bug 349812? (That new bug already have patch)
Comment 4 cmtalbert 2006-08-28 08:15:17 PDT
(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 ***
Comment 5 Joey Minta 2006-08-28 08:17:43 PDT
(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?
Comment 6 Stefan Sitter 2007-01-19 13:17:32 PST
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.
Comment 7 Stefan Sitter 2007-01-19 13:26:04 PST
*** Bug 365152 has been marked as a duplicate of this bug. ***
Comment 8 Stefan Sitter 2007-01-19 13:39:07 PST
*** Bug 365800 has been marked as a duplicate of this bug. ***
Comment 9 Stefan Sitter 2007-01-19 13:59:42 PST
*** Bug 364130 has been marked as a duplicate of this bug. ***
Comment 10 Damian Szczepanik 2007-01-19 14:26:31 PST
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?
Comment 11 Matthew (lilmatt) Willis 2007-01-31 15:20:02 PST
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.

:(
Comment 12 cmtalbert 2007-01-31 15:53:31 PST
*** Bug 363121 has been marked as a duplicate of this bug. ***
Comment 13 Matthew (lilmatt) Willis 2007-01-31 18:03:54 PST
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"
Comment 14 Emerson Prado 2007-02-01 03:57:57 PST
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
Comment 15 Stefan Sitter 2007-02-19 12:43:59 PST
*** Bug 370936 has been marked as a duplicate of this bug. ***
Comment 16 cmtalbert 2007-02-22 09:54:49 PST
*** Bug 368269 has been marked as a duplicate of this bug. ***
Comment 17 Bas van den Bosch 2007-02-22 11:51:14 PST
(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.
Comment 18 Ray Kiddy 2007-02-22 13:00:01 PST
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.
Comment 19 Matthew (lilmatt) Willis 2007-03-12 13:25:59 PDT
This will require reworking the datepicker to not use jsDate.  We won't block 0.5 on this.
Comment 20 Bas van den Bosch 2007-03-20 00:59:40 PDT
*** Bug 374556 has been marked as a duplicate of this bug. ***
Comment 21 cmtalbert 2007-05-03 08:15:03 PDT
*** Bug 374925 has been marked as a duplicate of this bug. ***
Comment 22 Martin Schröder [:mschroeder] 2007-05-10 07:24:21 PDT
*** Bug 380285 has been marked as a duplicate of this bug. ***
Comment 23 James Rome 2007-09-03 07:54:09 PDT
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.
Comment 24 James Rome 2007-09-03 07:54:46 PDT
I have Lightning .5 by the way...
Comment 25 Emerson Prado 2007-10-03 06:38:08 PDT
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
Comment 26 Daniel Boelzle [:dbo] 2007-11-08 02:21:25 PST
Fixed with bug 328442? We need to resolve these bugs for 0.8 => wanted-0.8.
Comment 27 James Rome 2007-11-08 06:22:32 PST
This seems to be gone in Lightning 0.7 for me in OS X
Comment 28 Daniel Boelzle [:dbo] 2007-11-22 06:05:28 PST
Clint, could you please verify whether this bug has been fixed with the fix of bug 328442?
Comment 29 Bas van den Bosch 2007-11-24 02:09:25 PST
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.
Comment 30 Daniel Boelzle [:dbo] 2007-11-25 10:03:40 PST
Fixed with bug 328442 per comment #29.
Comment 31 Emerson Prado 2007-11-26 08:42:37 PST
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.

Note You need to log in before you can comment on or make changes to this bug.