Tickets :: [#4794] Wrong eventduration with imported calendars

6.0.0-beta1

7/26/25

Summary	Wrong eventduration with imported calendars
Queue	Kronolith
Queue Version	HEAD
Type	Bug
State	Resolved
Priority	2. Medium
Owners	jan (at) horde (dot) org
Requester	jrkuipers (at) lauwerscollege (dot) nl
Created	12/16/2006 (6797 days ago)
Due
Updated	04/19/2007 (6673 days ago)
Assigned	02/07/2007 (6744 days ago)
Resolved	04/19/2007 (6673 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	Yes

04/19/2007 08:34:39 AM	Jan Schneider	Comment #10 Assigned to Jan Schneider Taken from Horde Developers State ⇒ Resolved	Reply to this comment
Fixed in CVS.

02/18/2007 01:10:02 AM	Matt Selsky	Comment #9	Reply to this comment
This patch makes President's Day show up on Sunday instead of Monday. The US32Holidays.ics file has: BEGIN:VEVENT DTSTART;VALUE=DATE:20020218 DTEND;VALUE=DATE:20020219 SUMMARY:President's Day UID:DA5629E3-0F90-4E6D-B7AE-0935905C6FDD DTSTAMP:20050930T233908Z SEQUENCE:5 RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=2;BYDAY=3MO END:VEVENT Without the patch President's Day is a 2-day event.

02/15/2007 06:28:10 PM	Jan Schneider	Comment #8	Reply to this comment
See ~~ticket 4617~~

02/07/2007 10:58:11 PM	Jan Schneider	State ⇒ Assigned Assigned to Horde Developers

02/07/2007 06:30:17 PM	avo (at) trustsec (dot) de	Comment #7 New Attachment: Driver.php.diff	Reply to this comment
ianh (at) hardersoft (dot) com writes: [...] Importing Canadian Calendars made all full day events span two days. The calculated end date was increased by one day. Also, when viewing events remotely (through webdav interface) in Lightening, the end dates were shown one day too soon. [...] It seems to be wrong to add a day to the end of an all-day event in kronolith/lib/Driver.php. Also, I think that it is wrong to subtract a day from the end date when exporting an all-day event. I've attached a patch that changes Driver.php accordingly. There seems to be another bug in Driver.php. One of the comments says that DTEND matches YYYYMMDDT2359(59\|00), i.e. the second may be 59 or 00. But the code doesn't check whether the _minute_ is 59; instead the code checks whether the _second_ is 59. This bug gets also fixed by our patch.

12/28/2006 10:53:20 PM	ianh (at) hardersoft (dot) com	Comment #6	Reply to this comment
Similar problem occurred with Kronolith v 2.1.4 and PostgreSQL backend. Importing Canadian Calendars made all full day events span two days. The calculated end date was increased by one day. Also, when viewing events remotely (through webdav interface) in Lightening, the end dates were shown one day too soon. Thus, full day events would show an error that the end date precedes the start date. Reverting to 2.1.2 fixed the problem.

12/16/2006 09:46:49 PM	jrkuipers (at) lauwerscollege (dot) nl	Comment #5 New Attachment: events.csv	Reply to this comment
Can you please upload a small test file? Attached a small icalendar file from kronolith (fw3). And a csv version

12/16/2006 09:36:22 PM	jrkuipers (at) lauwerscollege (dot) nl	Comment #4 New Attachment: events.ics	Reply to this comment
Can you please upload a small test file? Attached a small icalendar file from kronolith (fw3).

12/16/2006 09:30:33 PM	Chuck Hagenbuch	Comment #3 State ⇒ Feedback	Reply to this comment
Can you please upload a small test file?

12/16/2006 09:21:11 PM	jrkuipers (at) lauwerscollege (dot) nl	Comment #2	Reply to this comment
FYI: the imported values of the begin and enddate are ok.

12/16/2006 09:17:45 PM	jrkuipers (at) lauwerscollege (dot) nl	Comment #1 Priority ⇒ 2. Medium State ⇒ Unconfirmed Queue ⇒ Kronolith Summary ⇒ Wrong eventduration with imported calendars Type ⇒ Bug	Reply to this comment
When a calendar is imported (csv or icalendar), the calculated eventduration of multiday events is wrong. A negative number is dispayed! When the begin- or enddate is changed and after that changed back to the imported value the duration is calculated right.