Re: [calsify] JSCalendar duration vs. end time

[Garry Shutler <[e-mail]>]

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.

-
*Garry Shutler*
CTO & Co-founder, Cronofy
Scheduling Everything for Everyone


On Fri, 15 Feb 2019 at 09:08, Marten Gajda <[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]> <[e-mail]> *Im
> Auftrag von *Neil Jenkins
> *Gesendet:* Freitag, 15. Februar 2019 00:20
> *An:* [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 [e-mail]://www.ietf.org/mailman/listinfo/calsify
>
> --
> Marten Gajda
> CEO
>
> dmfs GmbH
> Schandauer Straße 34
> 01309 Dresden
> GERMANY
>
> phone: [phone]
> email: [e-mail]
>
> Managing Director: Marten Gajda
> Registered address: Dresden
> Registered No.: AG Dresden HRB 34881
> VAT Reg. No.: DE303248743
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify
>