326868 - Event times incorrectly rendered in views. Timezone or DST calculation problems?

Status: RESOLVED DUPLICATE of bug 296659

(Calendar :: Internal Components, defect)

Description

[MCT]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051107 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060205 Mozilla 

I am in Melbourne/Australia where our normal TZ is UTC+10, but currently we are in DST so TZ=UTC+11.

I create an event that goes from 9:00 am to 10:00 am, but it gets rendered in all views as starting at 8am! It displays correctly in the event dialog when you retrieve the event by double clicking on the view.

Sorry...could not tell if this behaviour is covered by an existing open bug.

Reproducible: Always

Steps to Reproduce:
Set your timezone to Melbourne and create an event. May be peculiar to Windows.

Comment 1

[Stefan Sitter [:ssitter]]

What product do you use? Sunbird, Lightning or Calendar Extension?

What version do you use? 0.2? 0.3a1? A nightly build?

Can you reproduce the error with a current nightly build from
http://ftp.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-trunk/ ?

Comment 2

[MCT]

Sorry, thought the Build Identifier in the initial description made this clear.

Using standalone Sunbird. Nightly Build from 5th Feb, however this problem also existed in a nightly build I downloaded in early Jan. The problem seems to have been introduced with the 'new views', as the old views were working OK in this respect.

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

The current theory is that our timezone-guessing code is making a mistake.  For Lightning, the workaround is to set your timezone by hand in the Lightning pref pane.  This workaround isn't yet available in Sunbird.

Comment 4

[MCT]

The bit that I don't understand though is why is the timezone calc stuff as used in the views different to what is used in the event dialog, where it still shows correctly. Regardless of whether the event times are stored in UTC or local, if the wrong tz is used, this would only matter if you were looking at all your appointments in UTC! 

Comment 5

[Stefan Sitter [:ssitter]]

Results of some testing:

Linux:

Tested with Thunderbird 1.6a1 (20060220) + Lightning 2006-02-20-07-trunk build and Sunbird 2006-02-20-07-trunk build. Local timezone and Lightning timezone were set to Australia/Melbourne: OK, times in view and edit event dialog are the same.

Windows 2000:

Tested with Thunderbird 1.5 (20051201) + Lightning 2006-02-19-07-mozilla1.8 build and Sunbird 2006-02-20-07-trunk build. Local timezone and Lightning timezone were set to Australia/Melbourne:
    'Automatic adjustment for daylight saving time' is enabled:
        Lightning: OK, times in view and edit event dialog are the same.
        Sunbird: Failure, times in edit event dialog are off by +1 hour.

    'Automatic adjustment for daylight saving time' is disabled:
        Lightning: Failure, times in edit event dialog are off by -1 hour. 
        Sunbird: OK, times in view and edit event dialog are the same.

Might be a Windows only problem but I don't find a setting similar to 'Automatic adjustment for daylight saving time' on Linux to verify different behavior.

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

Since this turns out not to be the tz guessing code, and it could cause someone to miss a meeting, I think this needs to block 0.1.

Comment 7

[Joey Minta]

Given that the main difference between the dialog and the views is the use of jsDate, it'd be helpful to get some dump() output related to that.  Is jsDate coming out different in the windows 2000 version?  I'd also suggest that setting the timezone explicitly in Lightning to Australia/Melbourne might be skewing results.  That timezone *does* have daylight savings, regardless of whether your window's settings have it.  Sunbird, which doesn't expose true tz-setting widgets yet, would be the pure case, in my mind.

Comment 8

[Dan Mosedale (:dmosedale, :dmose)]

Joey was right on both counts.  The reason this isn't seen by default is because the time zone guessing code incorrectly picks Atlantic/Canary when the Windows TZ is set to "Melbourne, don't adjust for DST" , which doesn't happen to expose the problem (bug 328996).  When Lightning is explicitly set to Melbourne time in this environment, adding a couple of dumps here:

http://lxr.mozilla.org/seamonkey/source/calendar/base/content/calendar-event-dialog.js#148

shows us that jsDate is indeed the guilty party:

startDate = 2006/02/28 10:00:00 /mozilla.org/20050126_1/Australia/Melbourne
endDate = 2006/02/28 11:00:00 /mozilla.org/20050126_1/Australia/Melbourne
startDate.jsDate = Mon Feb 27 2006 23:00:00 GMT+0000 (AUS)
endDate.jsDate = Tue Feb 28 2006 00:00:00 GMT+0000 (AUS)

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

It may be possible to hack around this by comparing startDate.timezoneOffset with startDate.jsDate.getTimezoneOffset() * 60, and if they differ, patching the resulting jsDate to compensate for the amount of the difference.

Comment 10

[gekacheka]

The problem is that the default timezone is not guaranteed to be the same as the OS timezone (the user can change the default timezone to something different via the preference option, and may change the os timezone independently).  This is exacerbated by the problems guessing the wrong timezone.  Changing the "automatically adjust for daylight saving time" setting effectively changes the timezone, since it changes the timezone rules.

Therefore cannot rely on calDate.getInTimezone(defaultTimezone) to return a calDateTime where .jsDate fields match the calDateTime fields.

Instead, must convert from calDate to jsDate by fields,
and convert back from jsDate to calDate by fields.  (This is effectively what conversion is proposed for the future by-fields datetimepicker, bug 92174 comment 47.)

(ref: bug 296659 advocates methods to do conversion by fields.  ItemDialog in bug 298102 has always converted between calDateTimes and jsDates this way, and doesn't exhibit this problem.)

Comment 11

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: patch, v1

This does approximately what gekacheka suggests, taking advantage of existing code in jsDateToFloatingDateTime and in the calDateTime.jsDate getter to do most of the work for us.  This fix also makes some changes to the event dialog to force the default timezone on various dates that weren't doing so already.  Right now, this fix effectively forks jsDateToDateTime and fixes only the copy in calendar-event-dialog.js.  A reasonable argument could be made that we should just  fix the master copies of this function and not fork it yet again, though that may be riskier.  Thoughts?

Comment 12

[Dan Mosedale (:dmosedale, :dmose)]

After a bunch of code-reading and deliberation, Joey and I have come to the conclusion that trying to partially fix this is likely to result in weird breakage, and trying to completely fix it is too risky for 0.1.  The right fix is really follow gekachekas suggestion in bug 296659 more closely, so marking this as a duplicate of that.  Ill mark that bug for release-noting.

*** This bug has been marked as a duplicate of 296659 ***