| Summary | Recuring (not-full-day) events seems to break FreeBusy |
| Queue | Kronolith |
| Queue Version | 2.1.2 |
| Type | Bug |
| State | Resolved |
| Priority | 2. Medium |
| Owners | Horde Developers (at) |
| Requester | horde (at) addelei (dot) nu |
| Created | 8/14/06 (7257 days ago) |
| Due | |
| Updated | 9/22/06 (7218 days ago) |
| Assigned | 8/20/06 (7251 days ago) |
| Resolved | 9/22/06 (7218 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | No |
State ⇒ Resolved
State ⇒ Assigned
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Type ⇒ Bug
Summary ⇒ Recuring (not-full-day) events seems to break FreeBusy
Queue ⇒ Kronolith
New Attachment: event.ics
August 14:th to August 18:th, seems to break Freebusy by completely
filling the person's calendar.
Looking at the code, it seems that the startdate on recurring events
returned by Kronolith::listEvents (called in lib/Kronolith.php at line
822*) is set to the last day after the recursion end, while enddate is
set to the original end date (as set in the calendar). This makes
$duration (lib/Kronolith.php, line 852) negative - effectively filling
the calendar.
For debugging, I've added the following right after the calculation if
$duration:
<code>
if ($duration < 0) print_r($event);
</code>
With the attached event.ics file, I get five Kronolith_Event_sql
objects, one for each day the event is recurring (the $day variable,
line 846, is correctly set). On each object, the $start property is
2006-08-19 while the $end property is 2006-08-14. Based on the
following code (including the comment "Make sure that we're using the
current date for recurring events", I would guess that the $start
property should have been 2006-08-14 instead.
I've tried to trace the error backwards to Kronolith::listEvents, but
I seem to get lost in the code.
* All line numbers might be slightly off since I've been adding and
removing lines consisting of debug-related print_r()'s!