Re: [calsify] JSCalendar duration vs. end time

["Alexander Nimmervoll" <[e-mail]>]

I agree that having 2 different representations is confusing and should be avoided. Similar problem with COUNT and UNTIL in RRULE.

 

But looking into it also from client UI perspective almost every client allows you to choose start and end time and not start time and duration for an event.

Is there a reason you choose start time and duration vs start time and end time? You also use start and due for JSTask and no duration there, again confusing. There shouldn’t be different representations for events and tasks.

Using start and end time allows also an easier specification of different start and end timezones and is less confusing for triggers related to start or end.

 

During CalConnect we also mentioned the airline example where start and end times are different from scheduled durations but that can’t be modelled in iCalendar as well.

 

Cheers,

Alex

 

Von: calsify <[e-mail]> Im Auftrag von Robert Stepanek
Gesendet: Donnerstag, 14. Februar 2019 17:02
An: [e-mail]
Betreff: [calsify] JSCalendar duration vs. end time

 

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  <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-11> 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