If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED FIXED

Status

Calendar
Sunbird Only
RESOLVED FIXED
12 years ago
10 years ago

People

(Reporter: Robin Edrenius, Assigned: Michiel van Leeuwen (email: mvl+moz@))

Tracking

Dependency tree / graph

Details

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

12 years ago
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

12 years ago
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

12 years ago
(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+.
(Reporter)

Comment 3

12 years ago
(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
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All

Comment 4

12 years ago
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

12 years ago
(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

12 years ago
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

12 years ago
Created attachment 202360 [details]
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

12 years ago
(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

12 years ago
(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

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

Comment 11

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

Comment 12

12 years ago
(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+

Updated

12 years ago
Blocks: 330188

Comment 13

12 years ago
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.
Depends on: 322768
Created attachment 216652 [details]
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

12 years ago
(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

12 years ago
(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.
(Assignee)

Comment 17

12 years ago
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.
(Assignee)

Comment 18

12 years ago
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.
(Assignee)

Comment 19

12 years ago
Created attachment 217199 [details] [diff] [review]
work in progress

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

Comment 20

12 years ago
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.
(Assignee)

Comment 21

12 years ago
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.
(Assignee)

Comment 22

12 years ago
Created attachment 217471 [details] [diff] [review]
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.
Attachment #217471 - Flags: first-review?(jminta)

Comment 23

12 years ago
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.
Attachment #217471 - Flags: first-review?(jminta) → first-review-
(Assignee)

Comment 24

12 years ago
Created attachment 217741 [details] [diff] [review]
new filter

Now with assigning to g*Date, nullchecks and actually works.
Assignee: mostafah → mvl
Attachment #217471 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #217741 - Flags: first-review?(jminta)

Comment 25

12 years ago
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.
Attachment #217741 - Flags: first-review?(jminta) → first-review+
(Assignee)

Comment 26

12 years ago
patch checked in.
Bug 333362 filed for zero-length issue
Bug 333363 filed for the providers.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.