306157 - All day event in event list two days, the correct day and the day after

Status: RESOLVED FIXED

(Calendar :: Sunbird Only, defect)

Description

[Robin Edrenius]

All day event is seen in the event list for both the day of the all day event
and the day after.
If I change DTEND to the same date as DTSTART, I only see it in the event list 
the right date (as it is supposed to be), I don't see it in the calendar though.


Steps to reproduce:
1. Create an all day event
2. Choose 'show currently seleceted day' in the event-list
3. select the day after the allday event

Result: You see the event in the event list.

Expected result: You should only see the event in the list if you select the day
the all day event occur.

Comment 1

[Carl Greco]

An all day event that spans several days across a weekend does not appear in the
following week or the following day views.  It does however appear in the
originating day and week view as well as the multiple week and month views.

Comment 2

[Stefan Sitter [:ssitter]]

(In reply to comment #0)
> All day event is seen in the event list for both the day of the
> all day event and the day after.

I can confirm this with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/
20051014 Mozilla Sunbird/0.2+.

Comment 3

[Robin Edrenius]

(In reply to comment #2)
> I can confirm this with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/
> 20051014 Mozilla Sunbird/0.2+.

Thanks, changing status to NEW

Comment 4

[Stefan Sitter [:ssitter]]

As far as I understand it an allday event (e.g. at 20-Oct-2005) is stored like 
this:
startdate: 2005/10/20 00:00:00
enddate:   2005/10/21 00:00:00

'Currently Selected Day' filters events from 00:00:00 to 23:59:59.

The event above matches 2005/10/20 00:00:00 *and* 2005/10/21 00:00:00 and is 
therefore displayed on both days.

This malfunction also applies to non-allday events that end at 00:00:00.

Comment 5

[Torsten]

(In reply to comment #4)
> As far as I understand it an allday event (e.g. at 20-Oct-2005) is stored like 
> this:
> startdate: 2005/10/20 00:00:00
> enddate:   2005/10/21 00:00:00

All-day-events are stored like this:
DTSTART;VALUE=DATE:20051107
DTEND;VALUE=DATE:20051108
The event ends on 08.11.2005 and therefore it is only a one-day-event.



> 
> 'Currently Selected Day' filters events from 00:00:00 to 23:59:59.
> 
> The event above matches 2005/10/20 00:00:00 *and* 2005/10/21 00:00:00 and is 
> therefore displayed on both days.
> 
> This malfunction also applies to non-allday events that end at 00:00:00.

Comment 6

[Torsten]

The described behaviour is comparable to the one described in the resolved bug 207121.

I can confirm this with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051108 Mozilla Sunbird/0.3a1+, but only for remote calendars.

Steps to reproduce:
1. Create an all-day-event in a remote calendar 
   => the event is shown correctly in the calednar AND in the event list
2. Reload the remote calendar
   => The event is shown correctly in the calendar but with a wrong end date
      (on day to late) in the event list

For local calendars, the event is displayed correctly in the event list, even after restarting sunbird. Apparently, some informations are lost while reloading remote calendars. This also holds for alarms (see bug 315051).

Comment 7

[Stefan Sitter [:ssitter]]

Attachment: illustration of problem

(In reply to comment #6)
Hello Torsten,
I think your problem is another one than the problem adressed in this bug. See attachment for an illustration of the adressed problem.
Stefan

Comment 8

[Torsten]

(In reply to comment #7)
> I think your problem is another one than the problem adressed in this bug. See
> attachment for an illustration of the adressed problem.

I have to admit that I really misunderstood the description of this bug. 

But maybe (or even probably) the two problems
1. Showing an event in the list of the currently selected day 
   even it is an all-day-event of the day before and
2. Showing the end date of an all-day-event one day too late 
   (at least for remote calendars) 
are related in some way.

Would it be helpful to file a seperate bug for the second issue?

Comment 9

[Stefan Sitter [:ssitter]]

(In reply to comment #8)
> Would it be helpful to file a seperate bug for the second issue?

I think so. Lets try to keep one problem per bug. If possible please add an URL to a (minimal) remote calendar that shows that problem.

Comment 10

[Joey Minta]

*** Bug 315703 has been marked as a duplicate of this bug. ***

Comment 11

[Joey Minta]

Robin,
    How are we doing on this?  If it's still an open issue, my feeling is that it should block 0.3a2.

Comment 12

[Robin Edrenius]

(In reply to comment #11)
> Robin,
>     How are we doing on this?  If it's still an open issue, my feeling is that
> it should block 0.3a2.
> 

I still see it on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060324 Mozilla Sunbird/0.3a1+

Comment 13

[Joey Minta]

Bug 322768 helps a fair bit with this.  We get the date right at least, but we lose the 'All day' string.  I'm inclined to vote for taking that patch and then tidying things up, rather than trying to hack a fix here.  Adding dependency for now.

Comment 14

[Manuel Vázquez Acosta]

Attachment: Sunbird nightly build 2006-03-27 does not shows the issue

This screenshot was taken to sunbird nightly build from 2006-03-27. As you can see, the event is not display in the event list, the day after...

Comment 15

[Stefan Sitter [:ssitter]]

(In reply to comment #14)
> This screenshot was taken to sunbird nightly build from 2006-03-27. As you can
> see, the event is not display in the event list, the day after...

I still see the problem with Sunbird 0.3a1+ (20060329) and local timezone being UTC+1. I bet that the unifinder does not use correct timezone settings (similar to the problem in bug 315703).

Comment 16

[Joey Minta]

(In reply to comment #15)
> (In reply to comment #14)
> > This screenshot was taken to sunbird nightly build from 2006-03-27. As you can
> > see, the event is not display in the event list, the day after...
> 
> I still see the problem with Sunbird 0.3a1+ (20060329) and local timezone being
> UTC+1. I bet that the unifinder does not use correct timezone settings (similar
> to the problem in bug 315703).
> 
The bug I referenced hasn't had a checkin yet.  When I was looking at the code it looked more like a bug in dateUtils.js, rather than a timezone problem.  Accordingly, I added the calIDateTimeFormatter as a dependency, since that will rip out dateUtils.js and the buggy code along with it.

Comment 17

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

bug 322768 changed things slightly, but it isn't fixed yet. Something weird is going on now: I now see an allday event in the unifinder as
Sun 5 Feb 2006 00:00 - Mon 5 Feb 2006 00:00
Same date, different day. Not sure why that's happening. Also still shows the hour.

Comment 18

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

Ignore my last comment. I filed that as bug 332738.
The fix for this bug would be to make unifinder.js refreshEventTree() use calIDateTime instead of jsDate. jsDate and calculations and timezone's don't go together.

Comment 19

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

Attachment: work in progress

Like this, except that it doesn't actually fix the bug. Maybe it's a provider bug after all.

Comment 20

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

The real problem seems to indeed be in the providers.
The memory provided (use by ics) uses .nativeTime, but doesn't take into account .isDate of calIDateTime. The result is somewhat wrong behaviour. But i'm not sure what would be right. We could make the provider use calIDateTime.compare, instead of working with .nativeTime. We could change the semantics of .nativeTime. We could try to correct .nativeTime in the provider.
All of them sound fragile, or might cause regression, or both.
For the storage provider, about the same story goes, except that you have to use nativeTime there, and correcting is a lot harder.

But before trying to fix this, we need to define how calICalendar.getItems works with .isDate, both in the start and endtime of the query, and for the items itself. Wihtout that defined, trying to fix this bug will be patchwork, waiting for the regressions.

Comment 21

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

A temporary workaround might be to leave the providers as-is, and add some check to the unifinder.js, to see if the event really is on the right date. That would be ugly, but would allow us to release sunbird0.3a2.

Comment 22

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

Attachment: extra filter

This patch seems to actually fix the issue. It's not pretty, but it works. If we decide to go with this, i will file follow-up bugs on the providers.

Comment 23

[Joey Minta]

Comment on attachment 217471 [details] [diff] [review]
extra filter

+// Store the start and enddate, because the providers can't be trusted when
+// dealing with all-day events. So we need to filter later. See bug 306157
+var gStartDate;
+var gEndDate;

The concept looks nice, but I feel like a substantial portion of this patch got left out.  In particular, where are we actually assigning values to these variables?

+   // Extra check to see if the events are in the daterange. Some providers
+   // are broken when looking at all-day events.
+   function dateFilter(event) {
+       return (event.startDate.compare(gEndDate) < 0 &&
+               event.endDate.compare(gStartDate) > 0);
+   }
+   gEventArray = gEventArray.filter(dateFilter);
In the 'All events' filter, won't gStartDate and gEndDate be null?  I think that will throw.

Comment 24

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

Attachment: new filter

Now with assigning to g*Date, nullchecks and actually works.

Comment 25

[Joey Minta]

Comment on attachment 217741 [details] [diff] [review]
new filter

r=jminta with bugs filed for the provider and probably for the zero-length midnigth case too, per IRC.

Comment 26

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

patch checked in.
Bug 333362 filed for zero-length issue
Bug 333363 filed for the providers.