| 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 | 07/24/2013 (4315 days ago) |
| Due | |
| Updated | 07/24/2013 (4315 days ago) |
| Assigned | 07/24/2013 (4315 days ago) |
| Resolved | 07/24/2013 (4315 days ago) |
| Milestone | |
| Patch | No |
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: 12489kronolith/lib/Event.php | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
http://git.horde.org/horde-git/-/commit/f0bebd4284bd36635b1f63be35089d01622e1729
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.
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.
ALWAYS increment the DTEND seconds.
I will hopefully provide a patch later after some further testing.
Priority ⇒ 1. Low
State ⇒ Feedback
Bug: 11976Priority ⇒ 3. High
Type ⇒ Bug
Summary ⇒ DTEND incremented on ical export for no real reason
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ No
State ⇒ Unconfirmed
$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.