Closed Bug 400318 Opened 17 years ago Closed 17 years ago

Time incorrectly recalculated when Lightning/Sunbird timezone does not match system timezone (datepicker)

Categories

(Calendar :: Internal Components, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ben, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Build Identifier: Lightning 0.7RC2 2007101603

If the timezone setting in Lightning/Sunbird does not match the timezone setting of the system, then when you try to change the time in the "New Event" dialog box, both the start and end time are recalculated incorrectly.

Reproducible: Always

Steps to Reproduce:
1. Change your Lightning/Sunbird timezone to something other than the system time zone.
2. Create a new event by clicking "File" -> "New" -> "Event..."
3. Click on the "Start" time.
4. Click on any other field (such as "Title")
5. Click back and forth between the "Start" time field and another field.

Actual Results:  
When you click off of the "Start" time field, the "Start" (and also the "End") time is changed to be several hours different from the desired time.

Expected Results:  
The time should not change simply by selecting the "Start" time field and then selecting another field.

With the "New Event" (or "New Task") dialog box open, if I change either of the times, they are recalculated to be an incorrect time. The time is always changed by a fixed number of hours that appears to depend on the difference between the system timezone and the Lightning time zone.

In my case, my Windows XP timezone is set to "Eastern Time (US & Canada)", and the Lightning/Sunbird timezone is set to "America/Boise". This causes the time to be decremented by 4 hours on each recalculation.

I've tested this by changing the Lightning timezone to "Europe/London", and by changing the Windows XP timezone to "Western Time (US & Canada)", in each case experiencing the same problem.

For example, if I change the time to be 12:00pm (either by typing or by using the time-picker), as soon as I click off the field onto another field, the date is changed to 8:00pm. If I click back on "Start Time" then back to another field, the "Start Time" is changed to 4:00am. If I click back on "Start Time" again, then back to another field, the time is changed to 12:00am. Each time decrementing by 4 hours.

The same problem occurs with the "End Time" field.
Known issue. Caused by Bug 337191 and the usage of jsdate in the prototype dialog. See also Bug 395800 Comment #1.
Confirming this issue and adding dependency to Bug 337191. The old dialog just displays the times wrong (Bug 337191) but the prototype dialog also changes the times on every update.
Status: UNCONFIRMED → NEW
Depends on: 337191
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
This behavior makes the date and time selection almost unusable in the prototype event dialog. Requesting blocking‑calendar0.8.
Flags: blocking-calendar0.8?
We're in the early stages of 0.8 development. Please mark bugs as wanted0.8? now, unless they are on the roadmap for 0.8
Flags: blocking-calendar0.8? → wanted-calendar0.8?
Just for reference purposes, the problem exists because our codebase freely mixes jsDate and calDateTime, see bug 328442. A possible cure would be to remove all uses of jsDate.
Depends on: 300605
Flags: wanted-calendar0.8? → wanted-calendar0.8+
Fixed with checkin for bug 328442?
Benjamin, could you please verify whether this bug has been fixed with the fix of bug 328442?
The timezone set in my Sunbird is América/São Paulo (I don't know why there's no Brasília — Brazil's capital which names the official Brazilian time zone — in the list) and the timezone set in Windows is (GMT-03:00)Brasília. I guess the problem  shouldn't happen to me, but it does.

Are you sure the problem is in difference between OS and Sunbird timezones?

The problem started with Sunbird 0.7 and my timezones was always in sync.

To me, every click adds 2 hours, exactly the difference between my local timezone and GMT (considering sunlight saving time).
I was thinking... Maybe we're are both right... Windows and Linux work with time in different ways... In Linux, you set your timezone and the system time is always GMT (to me, when the system time is 10 AM it shows me 8 AM)... In Windows, you set the timezone for the system then the system time is the same as your time zone (Win shows exactly the system time as your time)...

The problem is likely assigned to system time not to OS time.

P.S. When I say "system time" I mean the time of the PC clock, the hour shown in BIOs
btw, you set the severity of this bug as normal, but I can't use Sunbird this way... I had to go back to version 0.5
(In reply to comment #15)
> Benjamin, could you please verify whether this bug has been fixed with the fix
> of bug 328442?
> 

Daniel, this WFM now, with both Linux and Windows versions of both Sunbird and Lightening downloaded Nov. 24, 2007. I'm not sure what problem is being experienced by Marcio, but I am not experiencing this problem anymore.

Marcio, I'm going to mark this bug as WORKSFORME because as I described/experienced the bug it required the system timezone to be different than the Sunbird/Lightning timezone, so it sounds like you are having a different (although probably related) problem. You will probably want to file a separate bug report describing the problem you are experiencing.

- Ben
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Fixed with bug 328442 per comment #15 and following.
Depends on: 328442
No longer depends on: 300605
Resolution: WORKSFORME → FIXED
Sorry, I omitted an information that can explain my problem. I was using Sunbird 0.7 installed on Windows with a profile stored in a Linux server (through a SAMBA network) with calendars stored in the same Linux server.

Join this information with the Comment #18 and you will begin to understand that my problem seems to be the same of everyone here.

well, this can explain the problem but not solve it...

The timezone of the server is set to -02 h (with sunlightsaving time), the same as my Windows client. This way it seems Sunbird is taking into account the UTC time set within the linux server, instead of its local time (-02 h).

At first I'd installed back the 0.7 version, then I created another profile (local this time), and copy one of the calendars used before to the pc I use. Tried to change the hour of the events and everything worked fine (as I said before, OS and Sunbird timezones are the same). And then, I tried again the profile and calendars through network and "voilá"! The problem happened again (this time only for the hour of the end of events, I don't know why)...

My Sunbird, my Windows (client) and my Linux (server) are set to Brazilian time. And the problem occurs when I try to profiles thru network.

Target Milestone: --- → 0.8
I also am using Version 7.0 Sunbird and cannot set the correct time for appointment. When setting the "start" timeset automatically it changes without reason when I click on "end" or go to any other area of the site. If I add the time manually, the same thing happens. I am in CDT zone and show "America/Cancun".
(In reply to comment #28)
Don't forget that Cancun starts daylight savings time after the U.S. (April instead of March.) That could create an hour difference right there. For me, this bug caused an offset of two hours instead of one. I had to select "America/Chicago" so that the CDT timezone in Windows would match Sunbird's timezone and daylight savings time settings. This eliminated Sunbird's timezone calculations and bypassed this bug (as long as we don't travel anywhere...)
Performed some more tests... On Windows Vista this bug appears to be doubling any time zone calculations.

Setting system to a given timezone and Sunbird to a timezone 3 hours behind will result in an automatic 6 hour time difference when creating/editing an appointment. Recreated problem with timezones 1,2, and 4 hours apart.
You _must_ use the same timezone settings in Sunbird or Lightning _and_ your OS, otherwise you'll always have time or date calculation problems. There is no known bug in Sunbird or Lightning that should urge you to select not matching timezones. This information is valid for 0.8pre and the upcoming 0.8 release of Sunbird and Lightning.
(In reply to comment #32)
Then, why does Sunbird try to make any calculation at all? IMHO it should convert system time to GMT and then convert that to Sunbird's selected timezone. Once again, if it makes any calculation at all.
Well, to be honest, you don't have to. If you're planning to go abroad you can set certain events to a different timezone. At the moment you arive in a different zone, you adjust your systemclock and the times of the events will show right -> usercase 1 - For this one could argue that all event-times should be shown on the time they are planned regardlkess of the timezone.   

What if you plan meetings (online or through telephone) with people who are in different timezones. A meeting is planned in one timezone but in your place, it has to be shown at your time, not the time of your participants. -> usercase 2 -  this is the way lightning/sunbird works. 

As for the calculation in comment 34, 0.8 will solve this so both usercases will work as well as simply planning meetings in your own timezone and having all kinds of daylight-savingstimes.
I've been using the Lightning v .7 with Thunderbird v2.0.0.12 for some
time now.  The timezone settings of Windows and Lightning are the same.

The problem that I've been seeing when creating a new event on any
given date is the Start/End date picker gadgit does not reflect the
select Hour/Minute selected.  For example :

1) New Event - Choose a date in the future (ex 1 week from today)
2) Enter Title & Location
3) Click on Start Time :

 - click on :   Hour = 13    Minute = 00

The start time in the form is now set to 11:00.

4) Repeat with End Time

 - click on :   Hour = 16    Minute = 00

The END time in the form is now set to 06:00.
The start time in the form is now set to 19:00. *** changed from above
step 3**

It appears that the selection of a time value from the picker is not
working correctly. In some cases, wildly wrong by many hours... 

Steve, this bug is fixed for Lightning 0.8 (see Status and Target Milestone). It's rather useless to add comments that the issue exists in Lightning 0.7 - the developers are already aware of this. Otherwise this bug report wouldn't exist and there wouldn't be a fix for the next release ;)
Instead of creating a new bug, I'll add a comment here first as there seems to be some common problem here.

Whenever I add or update an event from Lightning using the Provider for Google Calendar on my Windows Vista notebook, the event is moved one hour into the future.  I've been having this problem for about a year and it's slowly driving me insane.  I have to dismiss event alarms each and every hour once the event occurs unless I delete the event from my calendar.

I've tried this with the March 31st, 2008 nightly download of 0.8pre Lightning/Google Provider and the problem still exists.

My Lightning timezone is America/St_Johns.  My computer timezone is (GMT-03:30) Newfoundland.  I cannot use the same string setting on my computer and in lightning as like-named options don't exist. Both these timezones are GMT-3:30 during standard time and GMT-2:30 during daylight savings time.

Please see below for a debug log of adding a test event from Lightning.  Notice the hour difference in the event start/stop times.  This log was generated on March 10th with the latest nightly build as of that time.

Adding item Test Event

Logging object...
action: Setting Upload Data:
content: application/atom+xml; charset=UTF-8
data: <entry xmlns:gd="http://schemas.google.com/g/2005" xmlns:gCal="http://schemas.google.com/gCal/2005" xmlns="http://www.w3.org/2005/Atom">
 <category scheme="http://schemas.google.com/g/2005#kind" term="http://schemas.google.com/g/2005#event"/>
 <title type="text">Test Event</title>
 <content type="text">test event</content>
 <author>
   <name>someone@somewhere.net</name>
   <email>someone@somewhere.net</email>
 </author>
 <gd:transparency value="http://schemas.google.com/g/2005#event.opaque"/>
 <gd:eventStatus value="http://schemas.google.com/g/2005#event.confirmed"/>
 <gd:where valueString=""/>
 <gd:who email="someone@somewhere.net" rel="http://schemas.google.com/g/2005#event.organizer" valueString="someone@somewhere.net"/>
 <gCal:sendEventNotifications value="false"/>
 <gd:when startTime="2008-03-10T15:00:00-03:30" endTime="2008-03-10T16:00:00-03:30"/>
 <gd:extendedProperty name="X-MOZ-LASTACK" value=""/>
 <gd:extendedProperty name="X-MOZ-SNOOZE-TIME" value=""/>
 <gd:visibility value="http://schemas.google.com/g/2005#event.default"/>
</entry>
End object

calGoogleRequest: Requesting POST http://www.google.com/calendar/feeds/blahblahblah

Logging calIEvent:
   id: someidstring
   editurl:http://www.google.com/calendar/feeds/blahblahblah
   created:2008/03/10 17:08:46 UTC isDate=0
   updated:2008/03/10 17:08:47 UTC isDate=0
   title:Test Event
   content:test event
   transparency:OPAQUE
   status:CONFIRMED
   startTime:2008/03/10 16:00:00 /mozilla.org/20071231_1/America/St_Johns isDate=0
   endTime:2008/03/10 17:00:00 /mozilla.org/20071231_1/America/St_Johns isDate=0
   location:
   privacy:DEFAULT
   alarmOffset:null
   alarmLastAck:null
   snoozeTime:null
   isOccurrence: null
   Organizer:
       ID: MAILTO:someone@somwehere.com
           Name: Some Body
           Rsvp: false
           Is Organizer: yes
           Role: null
           Status: null
   Attendees:
   recurrence: no
Larry, thanks for the detailed debug info. From previous testing, this might be a Google issue that they don't correctly handle half-hour timezones. See bug 411558 for a similar issue.

Since the root cause is different from the one described in this bug and it is also fixed, could you file a separate bug in the Provider:GData Component? This way it won't go off my radar and I might get to testing it and get Google to fix it. Please also include the debug output from here.
You need to log in before you can comment on or make changes to this bug.