Subject: Re: [calsify] JSCalendar duration vs. end time

From: Doug Royer <[email-masked]>
Date: Wed, 6 Mar 2019 18:24:30 -0700

On 2/14/19 9:02 AM, 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 <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-11>).

This was a big debate at the time 2445 was coming out. The argument was 
that DURATION is a finite length of time. And that DTEND is a variable 
amount of time.

My argument against DTEND was:

DTSTART:2am DTEND:2am looks meaningless, except on the date when the 
clock kicks back 1 hour in which case it is a 1 hour meeting. And for 
recurring meetings, 6 months later it is a zero seconds long meeting.

Similar with: DTSTART:2am DTEND:1:30am for a 30-minute meeting on 
daylight saving change date.

Now throw in recurrences that happen to span those two dates and time 
zone change issues per year.

DTSTART:2am DURATION:1-hour makes sense to a person reading it.

Many argued that the ~odd~ DTSTART/DTEND may be desirable. I doubt 
anyone ever used it on purpose.

So they are not always equal. I argued for only one to exist, obviously 
I was in the minority.

I have always been in favor of deprecating DTEND.

However - iCalendar is the spec, and other representations of it, must 
adhere to whatever the latest spec says, or the result will be the IETF 
has 2 or more 'iCalendar' specifications.

-- 

--
Doug Royer (http://DougRoyer.US http://SoftwareAndServices.US)

---

From: "Robert Stepanek" <[email-masked]>
Date: Thu, 07 Mar 2019 03:09:04 -0500

On Thu, Mar 7, 2019, at 2:25 AM, Doug Royer 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 <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-11>).
> This was a big debate at the time 2445 was coming out. The argument was that DURATION is a finite length of time. And that DTEND is a variable amount of time.

> [...]

Thanks for the insight, Doug. Much appreciated to understand the history of this.

> However - iCalendar is the spec, and other representations of it, must adhere to whatever the latest spec says, or the result will be the IETF has 2 or more 'iCalendar' specifications

JSCalendar isn't another representation of iCalendar. While the two data models have much in common, we do not aim at 100% compatibility. The spec explicitly aims to avoid ambiguities and pitfalls of iCalendar.

Cheers,
Robert

---

From: Дилян Палаузов <[email-masked]>
Date: Fri, 08 Mar 2019 19:37:50 +0000

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Doug Royer <[email-masked]>
Date: Fri, 8 Mar 2019 19:30:54 -0700

On 3/8/19 12:37 PM, ÃÂÃÂ¸ÃÂ»ÃÂÃÂ½ 
> coffee-break and then a session “Topic B” for two hours.  You map this in iCalendar/CalDAV as (imprecise syntax):

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.

-- 

Doug Royer - (http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: Дилян Палаузов <[email-masked]>
Date: Sat, 09 Mar 2019 19:52:10 +0000

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,
> >

---

From: Doug Royer <[email-masked]>
Date: Sat, 9 Mar 2019 13:01:53 -0700

> one..four event(s) versus reissuing 28 events.  The latter option is … error prone.

And when they end across time zone changes, it is still a mess and 
ambiguous. Coming up with more of the same examples  does not make it 
unambiguous.

--