Re: [calsify] JSCalendar duration vs. end time

[Дилян Палаузов <[e-mail]>]

Hello Doug,

for an event with five slots, each slot containig six parallel meetings, there are 4 breaks and 30 sessions (so 34
events).  If the first slot gets prolonged/shortened, 28 events (4 breaks and 24 sessions) that are in the future, need
to be reissued, unless they have relative times.

If for each of the five slot, one of the events has relative time to the previous break, and the other parallel events
have start/stop/duration as that event, only one event per slot needs adjustment.

The benefit of having relative times (start/end) is to reissue less changes.  In this case it could be reissuing
one..four event(s) versus reissuing 28 events.  The latter option is … error prone.

Regards
  Дилян

On Fri, 2019-03-08 at 19:30 -0700, Doug Royer wrote:
> On 3/8/19 12:37 PM, Дилян 
> Палаузов [Masked] wrote:
> > 
> > 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.
> 
> So your choice is to make the calendar not match reality, or reissue 
> some new instances with the corrected values. When you re-issue new 
> instances, simply adjust them to be correct.
> 
> If you do not re-issue instances, the calendar does not match reality 
> anyway - so the point is really not relevant. Your simply picking which 
> properties in which components are incorrect.
> 
> If you reissue, simply set the 1st session end time to an accurate limit 
> (or ignore it is wrong). Set the break time to the correct start time 
> and 15 minute duration (or ignore it is wrong). And set the 2nd session 
> time to the correct values.
> 
> There is no one way to solve these issues. I think that makes it 
> ambiguous and poorly designed. There is no wrong way to get it done. The 
> meetings over times zone changes is a pain when implementations change 
> everything to DTEND, and relative entries are kind of correct in the 
> example you provide - or you have to reissue them anyway to make them 
> correct.
> 
> In both ways of thinking, the changed VEVENT components need to be 
> updated. It is just a matter of one of several ways of getting it done.
> Which is why I say it is ambiguous. There should be one way to get it 
> done recognized by all implementations.
> 
> I assert that all VEVENTs have some kind of duration, even when zero, 
> and can never be negative. However DTEND when not in UTC, is not always 
> obvious and a real pain over time zone changes.
> 
> I have found that developers will push for the method that makes any 
> changes to their current implementation easier. And sometimes, that 
> makes for ambiguous or difficult to understand specifications.
> 
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify