6.0.0-git
2019-03-23

[#12489] DTEND incremented on ical export for no real reason
Summary DTEND incremented on ical export for no real reason
Queue Kronolith
Queue Version 4.1.2
Type Bug
State Duplicate
Priority 1. Low
Owners
Requester stefan (at) baer (dot) rwth-aachen (dot) de
Created 2013-07-24 (2068 days ago)
Due
Updated 2013-07-24 (2068 days ago)
Assigned 2013-07-24 (2068 days ago)
Resolved 2013-07-24 (2068 days ago)
Milestone
Patch No

History
2013-07-24 16:36:46 Michael Rubinsky State ⇒ Duplicate
 
2013-07-24 16:36:21 Git Commit Comment #6 Reply to this comment
Changes have been made in Git (master):

commit f0bebd4284bd36635b1f63be35089d01622e1729
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Wed Jul 24 12:35:19 2013 -0400

     DTEND is non-inclusive, Kronolith_Event::End is inclusive.

     Bug: 12489

  kronolith/lib/Event.php |    4 ++++
  1 files changed, 4 insertions(+), 0 deletions(-)

http://git.horde.org/horde-git/-/commit/f0bebd4284bd36635b1f63be35089d01622e1729
2013-07-24 16:17:52 stefan (at) baer (dot) rwth-aachen (dot) de Comment #5 Reply to this comment
OK, then this bug can be closed I think. Sorry for my confusion.
2013-07-24 16:14:47 Michael Rubinsky Comment #4 Reply to this comment
Here $end->sec is incremented with the intention, that DTEND MUST be 
later than DTSTART. But it is incremented whether it's neccessary or 
not. If DTEND already IS later than DTSTART, a second will be added 
on every ical export.
No, this is not the reason it is incremented. According to RFC 2445 
the DTEND field is a non-inclusive. In other words, the actual event 
ends one second BEFORE the value of DTEND. Kronolith, on the other 
hand stores the event end time as an inclusive value, i.e., the event 
ends exactly on the second specified. We therefore have to increment 
the DTEND value by one second so that the value presented in the iCal 
file is non-inclusive.
2013-07-24 13:15:56 stefan (at) baer (dot) rwth-aachen (dot) de Comment #3 Reply to this comment
I don't know, if it's a duplicate of this bug. It's simply wrong to 
ALWAYS increment the DTEND seconds.

I will hopefully provide a patch later after some further testing.
2013-07-24 02:30:47 Michael Rubinsky Comment #2
State ⇒ Feedback
Priority ⇒ 1. Low
Reply to this comment
Possibly a duplicate or at least related to Bug: 11976
2013-07-24 02:19:21 stefan (at) baer (dot) rwth-aachen (dot) de Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 3. High
Summary ⇒ DTEND incremented on ical export for no real reason
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ No
Reply to this comment
Line 640 in kronolith/lib/Event.php (exporting icals):
$end->sec++;

Here $end->sec is incremented with the intention, that DTEND MUST be 
later than DTSTART. But it is incremented whether it's neccessary or 
not. If DTEND already IS later than DTSTART, a second will be added on 
every ical export.

This leads to duplicates when syncing with the Synthesis SyncML 
client.  Since Horde doesn't do a correct SlowSync (no duplicate 
elimination), the Synthesis guys built a duplicate elimination into 
their client. But since the events differ by one second (incrementing 
on each new SlowSync!!), this duplicate elimination fails.

Even without syncing this bogus incrementation by one second could 
lead to wrong times. Export the event and import it into horde again 
and repeat this 60 times, the end time of the event is moves by a 
whole minute!

I would check, if the end time differs from the start time and ONLY in 
that case do the incrementation on the end second.

Saved Queries