311983 - Sunbird - Incorrect date and time set for new event when using GMT+12 timezone

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[Andrew C]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

I live in New Zealand which is normally 12 hours ahead of GMT (13 hours during
daylight savings).  In the latest trunk nightly (2005-10-08-08-trunk) of
Sunbird, it incorrectly sets the start time of new event to 13 hours before the
start period clicked on.  It didn't do this for the 0.2 release.  If I set my
timezone to GMT +11 hours then the events are created as expected.


Reproducible: Always

Steps to Reproduce:
1. Set timezone to GMT + 12 and start Sunbird
2. Double click on any area to make a new event say 10 a.m.
3. New Event dialog box appears with start time set to 13 hours before (i.e. 9
a.m. the day before)
4. Change time zone to GMT +11 and restart Sunbird
5. Creating new events occurs as I expect

Actual Results:  
The new event dialog box appears with the start date/time set to 13 hours
earlier than I expected.

Expected Results:  
The new event dialog box should appear with the initial start date/time set to
the  date/hour I clicked on.

Doesn't like a time zone of GMT +12 or GMT +13 :(

Comment 1

[Joey Minta]

Wow, what nice timing.  I was actually working on this exact problem via email
with another user in Australia.  As it turns out, the way tzdata.c stores the
timezones, it's impossible for us to ever guess the user's timezone correctly
when a user is in the southern hemisphere.  Patch to follow that makes
everything work nicely for me even with a system timezone set to New Zealand.

Status: NEW

Comment 2

[Joey Minta]

Attachment: flip tz offsets and check again

There previously was a comment in the guessSystemTimezone() function expressing
puzzlement about why standard/summer tz data seemed backwards.	This bug is an
expression of that confusion.  To fix this, the guess function now also checks
for the reverse equivalence of the data.  In order to try and remove more
confusion in the future, i've renamed summertz* to tz*1 and wintertz* to tz*2
(which makes this patch bigger than expected).	It also fixes one javascript
strict warning.

Comment 3

[MCT]

Not quite there yet Joey...with your new patch this is what I got:

Guessing system timezone:
TZoffset1: +1000
TZoffset2: +1100
TZname1: AUS Eastern Standard Time
TZname2: AUS Eastern Daylight Time
gDefaultTimezone: /mozilla.org/20050126_1/Asia/Sakhalin


And when clicking on a day view:

Fetching events from 2005/10/13 01:00:00 /mozilla.org/20050126_1/Asia/Sakhalin
to 2005/10/14 01:00:00 /mozilla.org/20050126_1/Asia/Sakhalin
all day:   true
startdate: 2005/10/13 00:00:00 /mozilla.org/20050126_1/Asia/Sakhalin
enddate:   2005/10/13 00:00:00 /mozilla.org/20050126_1/Asia/Sakhalin
duration:  0
all day:   false
startdate: 2005/10/13 10:00:00 /mozilla.org/20050126_1/Asia/Sakhalin
enddate:   2005/10/13 11:00:00 /mozilla.org/20050126_1/Asia/Sakhalin
duration:  1
all day:   false
startdate: 2005/10/13 11:00:00 /mozilla.org/20050126_1/Asia/Sakhalin
enddate:   2005/10/13 12:30:00 /mozilla.org/20050126_1/Asia/Sakhalin
duration:  1.5
all day:   false
startdate: 2005/10/13 13:30:00 /mozilla.org/20050126_1/Asia/Sakhalin
enddate:   2005/10/13 14:30:00 /mozilla.org/20050126_1/Asia/Sakhalin
duration:  1
all day:   false
startdate: 2005/10/13 12:30:00 /mozilla.org/20050126_1/Asia/Sakhalin
enddate:   2005/10/13 13:30:00 /mozilla.org/20050126_1/Asia/Sakhalin
duration:  1
all day:   false
startdate: 2005/10/13 15:00:00 /mozilla.org/20050126_1/Asia/Sakhalin
enddate:   2005/10/13 16:00:00 /mozilla.org/20050126_1/Asia/Sakhalin
duration:  1


The event times are still correct in terms of my local times, but the timezone
is not right!

Comment 4

[Joey Minta]

patch checked in

(In reply to comment #3)
> gDefaultTimezone: /mozilla.org/20050126_1/Asia/Sakhalin

This is all I want.  This timezone has the same offsets as your actual timezone,
so things should work out effectively the same.  (For another example, Sunbird
puts me in Bogota, when I'm really in Indiana.)  Hopefully we'll have the
timezone picker wired up soon, so that you can fine-tune this guess.  The point
is, this fixes the problems of wrong dates/filters.

Comment 5

[MCT]

Joey - this seems to have created a consequential problem. Everything looks 
correct in the calendar views, but when I go to edit an event, the start and 
end times are out by an hour. They're correct on the view, but not in the 
dialog. Everything looks ok in the exported ical file.

I'm also not convinced the event filters are working OK - now seems to be 
wanting to search from 0100 to 0100 the next day, as stated by the dump. i.e. 
Also out by an hour?

Only thing I can think of is that daylight savings handling is broken in some 
parts of the code?  (We're not in DST now by the way, but will be soon!)

Comment 6

[jrx]

This bug seems to have reappeared sometime around the 20051124 build of Sunbird 0.3a1+.  When I double-click to create a new event, the event is actually placed +7 hours from where I clicked - I'm on Mountain Standard Time (GMT-7).  Please reopen.

Comment 7

[Robin Edrenius]

(In reply to comment #6)
> This bug seems to have reappeared sometime around the 20051124 build of Sunbird
> 0.3a1+.  When I double-click to create a new event, the event is actually
> placed +7 hours from where I clicked - I'm on Mountain Standard Time (GMT-7). 
> Please reopen.
> 

Reopening as per comment.

Comment 8

[Stefan Sitter [:ssitter]]

(In reply to comment #6)
> When I double-click to create a new event, the event is actually
> placed +7 hours from where I clicked - I'm on Mountain Standard Time (GMT-7). 
> Please reopen.

Reporter: Please try again with the 2005-11-27 Sunbird nightly build to verify if the error still exist for you.

Comment 9

[Stefan Sitter [:ssitter]]

(In reply to comment #6)
> This bug seems to have reappeared sometime around the 20051124 build of Sunbird
> 0.3a1+.  When I double-click to create a new event, the event is actually
> placed +7 hours from where I clicked - I'm on Mountain Standard Time (GMT-7). 
> Please reopen.

[e-mail]:
Does the error still exist for you with current nightly builds?

Comment 10

[jrx]

Seems fine now with 1208 build.
Sorry for the delayed reply, I didn't get an email notification of new comments on the bug until today.

Comment 11

[Stefan Sitter [:ssitter]]

(In reply to comment #10)
> Seems fine now with 1208 build.
> Sorry for the delayed reply, I didn't get an email notification of new comments
> on the bug until today.

Setting back to FIXED. (Bug 317864 fixed the problem that caused the reopening.)