Re: [calsify] JSCalendar duration vs. end time

[Michael Douglass <[e-mail]>]

On 2/15/19 04:44, Garry Shutler wrote:
> As the intended usage is so different, the similarity in naming can 
> only lead to confusion, which has been demonstrated here.
>
> If tasks were to have due and estimatedDuration (and perhaps something 
> like commencement rather than start), and events have start and 
> duration it would be more clear that they are different to each other.

The tasks extension (draft) already does that.

-
> *Garry Shutler*
> CTO & Co-founder, Cronofy
> Scheduling Everything for Everyone
>
>
> On Fri, 15 Feb 2019 at 09:08, Marten Gajda <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Am 15.02.19 um 08:09 schrieb Alexander Nimmervoll:
>>
>>     So why do you stick to due instead of start+duration for JSTasks?
>>
>     In contrast to events where the start is usually the more
>     important date, the due date of a task is usually far more
>     important than its start. So if you move a task in your calendar
>     you usually mean to move the due date.
>
>     In addition, in order to apply a duration you would always need a
>     start, but iCalendar and most implementations allow tasks to have
>     a due date only. And that's mostly what an average user cares about.
>
>     There is an iCalendar extension which adds an estimatedDuration
>     property to VTODO. Its meant to express that the actual execution
>     time of a task is usually shorter than the execution window (i.e.
>     the time between start and the due date).
>
>>     For the airline example with start and end time and fixed
>>     scheduled duration an idea would also be to use the
>>     estimatedDuration property for the scheduled flight-time or
>>     something similar.
>>
>     Where would be the difference to the duration we already have for
>     events? I think it might make sense to add a parameter which
>     expresses that the duration is only an estimate or may be subject
>     to change. We could, for instance, add a margin of error. For
>     example: a concert starts at 20:30 and is scheduled for 2 hours.
>     It may be delayed and the band may play a few more extra songs,
>     but due to local regulations there is a hard stop at 23:00.
>
>     I'd leave that to an extension of the current spec though.
>
>     Cheers,
>
>     Marten
>
>>     Cheers,
>>
>>     Alex
>>
>>     *Von:*calsify <[e-mail]>
>>     <mailto:[e-mail]> *Im Auftrag von *Neil Jenkins
>>     *Gesendet:* Freitag, 15. Februar 2019 00:20
>>     *An:* [e-mail] <mailto:[e-mail]>
>>     *Betreff:* Re: [calsify] JSCalendar duration vs. end time
>>
>>     On Fri, 15 Feb 2019, at 03:03, Robert Stepanek wrote:
>>
>>         Two arguments were raised in favor of adding an end time
>>
>>           * It simplifies translation of VEVENTs with DTSTART/DTEND
>>             from iCalendar.
>>
>>     Every client/server will need to be able to translate between
>>     duration and end already, so this is unlikely to be a significant
>>     hurdle to anyone.
>>
>>           * 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).
>>
>>     You kind-of mention this below, but I think it's important to
>>     note that *this argument is false*.. You cannot do this with
>>     recurrences as they exist right now in iCalendar.
>>
>>     On Fri, 15 Feb 2019, at 05:25, Alexander Nimmervoll wrote:
>>
>>         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.
>>
>>     The UI is independent of the underlying data format; as mentioned
>>     above you need to be able to translate between the two anyway.
>>
>>         Is there a reason you choose start time and duration vs start
>>         time and end time?
>>
>>     Yes.. There are many reasons why I strongly believe duration is
>>     preferable to end:
>>
>>      1. Having two representations for the same thing requires more
>>         code complexity, as there are two code paths to deal with.
>>      2. Recurrences always operate with duration regardless of
>>         whether it's actually specified as "end time", which is very
>>         confusing. With duration, it's very clean: you expand the
>>         start time according to the recurrence rule and then just
>>         inherit every other property (duration is just another
>>         property you inherit).
>>      3. There is no extra expressivity adding "end time". You can
>>         always convert from end time to duration. The /one/ exception
>>         is if the time zone data changed so that an offset transition
>>         now happened in the middle of the event AND in such a case
>>         you wanted the event to maintain its original end time rather
>>         than its original duration. I contend that:
>>          1. This case is exceedingly rare, and not important enough
>>             to make the common case more complex.
>>          2. No UI will ever be built to offer the user a choice for
>>             how to handle this situation, so it's even less important
>>             to handle.
>>          3. A better way to handle it would be to add an extra
>>             property that could be used to indicate the duration
>>             should be done in "wall clock" time; this would then also
>>             work for recurrences, which there is no solution for in
>>             iCalendar.
>>      4. Duration is guaranteed to be zero or positive, making it
>>         harder to create an invalid event and easier to check that an
>>         event object is valid. If you move the start of a series of
>>         events you don't need to make sure to keep the end in sync.
>>      5. Should time zone definitions change, it is more likely the
>>         duration should remain fixed and the end should shift (e.g.
>>         for flights).
>>
>>         Using start and end time allows also an easier specification
>>         of different start and end timezones
>>
>>     This is modelled differently in JSCalendar: there is a single
>>     time zone for the event, which is what it is scheduled in, but
>>     you can associate time zones with locations and mark that a
>>     location is where the event finishes, which is equivalent to the
>>     end time zone in iCalendar. This again is clearer, as it more
>>     closely matches the semantics of iCalendar (the "end" time zone
>>     is not used for scheduling/recurrences, it is only used for
>>     displaying in the UI after the necessary date arithmetic). And if
>>     time zone definitions change, again it's more likely the duration
>>     should stay constant rather than the end time (the example
>>     everyone uses for a different end time zone is flights: flying
>>     from Melbourne to LA is not going to get an hour shorter if
>>     California suddenly changes its daylight saving rules).
>>
>>     Neil.
>>
>>
>>     _______________________________________________
>>     calsify mailing list
>>     [e-mail]  <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/calsify
>
>     -- 
>     Marten Gajda
>     CEO
>
>     dmfs GmbH
>     Schandauer Straße 34
>     01309 Dresden
>     GERMANY
>
>     phone: [phone]
>     email:[e-mail]  <mailto:[e-mail]>
>
>     Managing Director: Marten Gajda
>     Registered address: Dresden
>     Registered No.: AG Dresden HRB 34881
>     VAT Reg. No.: DE303248743
>
>     _______________________________________________
>     calsify mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/calsify
>
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify