Re: [calsify] JSCalendar duration vs. end time

Hello,

imagine you book a room for 3:45 hours, and want to have there a session “Topic A” for one hour, a 0:15 hours for
coffee-break and then a session “Topic B” for two hours.  You map this in iCalendar/CalDAV as (imprecise syntax):

--
DTSTART: 8am
DTEND: 9am (or if you prefer DURATION: 1h) 
SUMMARY: Topic A
UID: 1
--
DTSTART;RELTYPE=FINISHTOSTART;REL-TO=UID:1 (per https://tools.ietf.org/html/draft-ietf-calext-ical-relations - the start
is defined as the end of the other event)
DURATION: 15minutes
SUMMARY: Tee time
UID: 2
--
DTSTART:RELTYPE=FINISHTOSTAR;REL-TO=UID:2
DTEND: 11:45am
SUMMARY: Topic B
UID: 3
--

So far so good.

Now, imagine the first session get longer as expected, e.g. 75 minutes.  The last session has to end in 11:45am, because
the room is booked only until then.  Under circumstances, the only event that needs to be updated is the first one, and 
the rest of the agenda will magically align, provided draft-ietf-calext-ical-relations makes progress.

In this case, for UID:2 you have to use DURATION and for UID:3 you have to use DTEND → Both are needed.

Regards
  Дилян

On Thu, 2019-02-14 at 17:02 +0100, Robert Stepanek wrote:
> During CalConnect XLIV in Zurich last week, discussion arose if the JSCalendar duration property is enough to define the time span of an event, or if an end time should be allowed as well (see the latest spec here).
> 
> Two arguments were raised in favor of adding an end time
> It simplifies translation of VEVENTs with DTSTART/DTEND from iCalendar.
> It allows to specify recurring events with a fixed end time even in case of time gaps (e.g. a recurring night club that has to close at a fixed time for legal reasons).
> 
> Our main concerns with adding an end time are:
> Having two representations to define an event time span adds complexity. This contradicts the stated goals of JSCalendar.
> Translation of DTSTART/DTEND to duration for one-time events is in almost all cases trivial. It does not require to rewrite existing calendar data.
> The "night club scenario" isn't covered by iCalendar either, as the same exact duration of a recurring even with DTEND must be applied to all members of the generated recurrence set (see RFC 5545, section 3.8.5.3). If anything, this scenario speaks for a new parameter on the RRULE.
> Durations are guaranteed to be zero or positive, which makes it harder to produce invalid events.
> 
> As it currently stands we therefore see no need for an end time property. Please let us know if you disagree.
> 
> Thanks,
> Robert
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify