307344 - event going over midnight does not show up in day view

Status: RESOLVED FIXED

(Calendar :: Sunbird Only, defect)

Description

[Simon Paquet [:sipaq]]

Build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050906
Mozilla Sunbird/0.2+

Steps to recreate:
Create an event on September 30th lasting from 22:45 to 0:15 on October 1st.

Expected Result:
Event should show up in all views.

Actual Result:
Event only shows up in week view, multiweek view and month view.
(This is also very nice, to watch bug 199732 BTW)


IMO this is a 0.3a1 blocker per the requirements on the wiki.

Comment 1

[Joey Minta]

Occurrences seem to be given in UTC, which is causing the problem.  For me, an
event that spans midnight will show up in the dayView if it finishes after 5am
(because I'm GMT-5).  Furthermore, this occurrence's start-time is set to 5am. 
The following is dumped for an event spaning 11pm 2005/09/05 to 12-noon 2005/09/06:

startdate: 2005/09/06 05:00:00 UTC
enddate:   2005/09/06 12:00:00 floating
duration:  12

Note that this actually creates an event box spanning 5am-5pm, instead of
midnight-noon.

I can also reproduce this behavior in week-view for events spanning
saturday-night (my week starts on sunday).

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

Attachment: update timezone code

The views used some very old stuff to detect the timezone. That code was
broken, and did random conversion to utc. we have better code for that now.
This patch makes the views use that code.
The patch may depend on bug 307416 to properly work, i think that depends on
the event and on the timezone you are in.

Comment 3

[Joey Minta]

Comment on attachment 195401 [details] [diff] [review]
update timezone code

This should probably also wait for bug 307557, otherwise our drawing of the
event view is going to get even slower.  Even after that's fixed though, I'd
prefer just calling calendarDisplayTimezone() once to a var, and then using it
everywhere.

Comment 4

[Michiel van Leeuwen (email: mvl+moz@)]

(In reply to comment #3)
> I'd prefer just calling calendarDisplayTimezone() once to a var, and then using 
> it everywhere.

No, that would be wrong. That way, you can't dynamicly update the timezone, or
you need to have pref observers all over the place.

Comment 5

[Joey Minta]

(In reply to comment #4)
> No, that would be wrong. That way, you can't dynamicly update the timezone, or
> you need to have pref observers all over the place.
> 

+    startDate =
aItemOccurrence.startDate.getInTimezone(calendarDefaultTimezone()).clone();
+    origEndDate =
aItemOccurrence.endDate.getInTimezone(calendarDefaultTimezone()).clone();

Instead of this, I meant I would prefer

+    var tz = calendarDefaultTimezone();
+    startDate = aItemOccurrence.startDate.getInTimezone(tz).clone();
+    origEndDate = aItemOccurrence.endDate.getInTimezone(tz).clone();

Just call it once inside this function.  You DON'T want it to change between
these lines.

Comment 6

[Joey Minta]

Comment on attachment 195401 [details] [diff] [review]
update timezone code

r=jminta with the changes from comment #5, and this does need bug 307416, for
me.

Comment 7

[Michiel van Leeuwen (email: mvl+moz@)]

Patch checked in. Leaving open, because to really fix the problem, we need bug
307416 fixed.

Comment 8

[Simon Paquet [:sipaq]]

Michiel, Joey, is this bug fixed now, now that bug 307416 has been fixed?

Comment 9

[Joey Minta]

(In reply to comment #8)
> Michiel, Joey, is this bug fixed now, now that bug 307416 has been fixed?

Not quite yet.  Now we're getting the event from getItems, but it isn't making
it into createEventBoxInternal. 20050920.

Comment 10

[Joey Minta]

Oops, I didn't realize this patch hadn't been checked in.  With this patch, then
yes, the bug is fixed for me.

Comment 11

[Simon Paquet [:sipaq]]

mvl, jminta, in the 20050920 nightly on Win XP this bug is only partly fixed for
me. 

An event lasting from September 30 (22.45) to October 1 (00.50) shows up
correctly on September 30 but does not show up at all on October 1.

BTW I'm moving this bug to mvl, since he supplied the patch.

Comment 12

[Michiel van Leeuwen (email: mvl+moz@)]

Really checked in now. This should be fixed.