Closed Bug 315954 Opened 14 years ago Closed 14 years ago

multiday view fails to display events at the end of the week

Categories

(Calendar :: Internal Components, defect, major)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dmose, Assigned: dmose)

References

Details

(Keywords: dataloss)

Attachments

(1 file, 1 obsolete file)

Evening events on Saturday night are lost for me, and I'm in America/Los_Angeles.  This seems likely to be related to not accounting for timezones somewhere.  Though data isn't actually disappearing, it's been effectively hidden from the user, so it's more or less equivalent to dataloss.
The problem here seems to be in getting the nativeTime of a calDateTime with .isDate set.  Evaluate the following code-snippet in the jsconsole:

var cd1 = Components.classes["@mozilla.org/calendar/datetime;1"].createInstance(Components.interfaces.calIDateTime);
var cd2 = Components.classes["@mozilla.org/calendar/datetime;1"].createInstance(Components.interfaces.calIDateTime);
cd2.year = 2005;
cd2.month = 10;
cd2.day = 13;
cd2.hour = 0;
cd2.minute = 0;
cd2.second = 0;
cd2.timezone = "/mozilla.org/20050126_1/America/Bogota";
cd2.normalize();
cd1 = cd2.clone();
cd2.isDate = true;
cd1+','+cd1.nativeTime+'\n'+cd2+','+cd2.nativeTime;

This shows although the two dates have identical strings and seem to be the same time, their nativeTime values are different.  Sunbird's old views avoided this problem by (accidentally?) not setting .isDate to be true when calling getItems.  This problem can likewise be fixed by setting .isDate to be false in startDate/queryEndDate, although I'm not sure that this is the best option.

Suggestions for other solutions?
This looks like a bug in calDateTime to me.  Ill try and step through the C++ code in the debugger and see what I can figure out...
Assignee: nobody → dmose
If you've got ideas for how this code be coded more cleanly, I'm all ears...
Attachment #204316 - Flags: first-review?(mvl)
Comment on attachment 204316 [details] [diff] [review]
ensure nativeTime calculations on dates account for timezone changes

looks ok, but you could add some documentation on what .nativeTime mean when .isDate is set.
Attachment #204316 - Flags: first-review?(mvl) → first-review+
Patch updated with comments, license boilerplate additions, and whitespace tweaks; carrying forward review.
Attachment #204316 - Attachment is obsolete: true
Attachment #204973 - Flags: first-review+
Fix checked in.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.