Closed
Bug 306157
Opened 19 years ago
Closed 19 years ago
All day event in event list two days, the correct day and the day after
Categories
(Calendar :: Sunbird Only, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: robin.edrenius, Assigned: mvl)
References
Details
Attachments
(4 files, 1 obsolete file)
39.39 KB,
image/png
|
Details | |
103.46 KB,
image/png
|
Details | |
4.36 KB,
patch
|
Details | Diff | Splinter Review | |
3.64 KB,
patch
|
jminta
:
first-review+
|
Details | Diff | Splinter Review |
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•19 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•19 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•19 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•19 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.
(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.
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•19 years ago
|
||
(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
(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•19 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•19 years ago
|
||
*** Bug 315703 has been marked as a duplicate of this bug. ***
Comment 11•19 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•19 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•19 years ago
|
Blocks: sunbird-0.3a2
Comment 13•19 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
Comment 14•19 years ago
|
||
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•19 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•19 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•19 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•19 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•19 years ago
|
||
Like this, except that it doesn't actually fix the bug. Maybe it's a provider bug after all.
Assignee | ||
Comment 20•19 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•19 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•19 years ago
|
||
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•19 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•19 years ago
|
||
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•19 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•19 years ago
|
||
patch checked in.
Bug 333362 filed for zero-length issue
Bug 333363 filed for the providers.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•