6.0.0-beta1
7/24/25

[#4794] Wrong eventduration with imported calendars
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 (6795 days ago)
Due
Updated 04/19/2007 (6671 days ago)
Assigned 02/07/2007 (6742 days ago)
Resolved 04/19/2007 (6671 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch Yes

History
04/19/2007 08:34:39 AM Jan Schneider Comment #10
Assigned to Jan Schneider
Taken from Horde DevelopersHorde 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
02/07/2007 10:58:11 PM Jan Schneider State ⇒ Assigned
Assigned to Horde DevelopersHorde Developers
 
02/07/2007 06:30:17 PM avo (at) trustsec (dot) de Comment #7
New Attachment: Driver.php.diff Download
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 Download
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 Download
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.

Saved Queries