Subject: [calsify] JSCalendar duration vs. end time

From: Robert Stepanek <[email-masked]>
Date: Thu, 14 Feb 2019 17:02:06 +0100

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[1]).
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

Links:

  1. https://tools.ietf.org/html/draft-ietf-calext-jscalendar-11

---

From: "Alexander Nimmervoll" <[email-masked]>
Date: Thu, 14 Feb 2019 19:24:43 +0100

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 <[email-masked]> Im Auftrag von Robert Stepanek
Gesendet: Donnerstag, 14. Februar 2019 17:02
An: [email-masked]
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).

*	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).

*	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

---

From: "Neil Jenkins" <[email-masked]>
Date: Thu, 14 Feb 2019 18:20:24 -0500

>  * 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. 

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

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 14 Feb 2019 18:35:11 -0500

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

There's no particular difficulty for any client to convert an end time to a duration for storage and back again, given that any client which can parse arbitrary iCalendar already needs to know how to convert between the two.

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

Duration can't be negative, so you don't have "end before start" issues.

Duration is the unit used for recurrence calculations (as in: you need to calculate the duration of the first event using date math, then apply that duration to the future occurrences to calculate their actual end time).

Particularly if you have different timezones for the start and end, duration is easy to reason about!

The way airline flights book the start and end slots and the duration between is fuzzy within the flexibility of the flight speed is kind of a special case - but again the UI or even API for modifying an event and the underlying format don't need to be identical - and in even in the airline case it would be easier to validate the event based on known constraints of airline speed and fuel capacity.

Bron.

--
 Bron Gondwana, CEO, FastMail Pty Ltd
 [email-masked]

---

From: "Alexander Nimmervoll" <[email-masked]>
Date: Fri, 15 Feb 2019 08:09:17 +0100

Sounds reasonable.

I like the idea of the extra property indication "wall-time" for duration to
handle the fixed end time special case during DST shifts, discussed in the
nightclub example.

So why do you stick to due instead of start+duration for JSTasks?

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.

Cheers,

Alex

Von: calsify <[email-masked]> Im Auftrag von Neil Jenkins
Gesendet: Freitag, 15. Februar 2019 00:20
An: [email-masked]
Betreff: Re: [calsify] JSCalendar duration vs. end time

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. 

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.

---

From: "Robert Stepanek" <[email-masked]>
Date: Fri, 15 Feb 2019 03:20:06 -0500

> So why do you stick to due instead of start+duration for JSTasks?

There is no duration for tasks, the time properties of JSEvent and JSTask differ (see section 5 in the spec).

For events, a start is mandatory, optionally defining a duration.

For tasks, all time properties are optional. It can be defined to start at a certain time, be due at a certain time and have an estimated duration, but none of these are mandatory. We got asked to allow estimatedDuration and the time span between start and due to not match, which can be useful to highlight resource issues in project planning. Admittly, implementations still need to handle due-before-start issues for JSTask.

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

The estimatedDuration property is not defined for events.

Cheers,
Robert

---

From: Marten Gajda <[email-masked]>
Date: Fri, 15 Feb 2019 10:08:02 +0100

> 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 <[email-masked]> *Im Auftrag von *Neil Jenkins
> *Gesendet:* Freitag, 15. Februar 2019 00:20
> *An:* [email-masked]
> *Betreff:* Re: [calsify] JSCalendar duration vs. end time
>
>  
>
> 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. 
>
>  
>
>     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.
>
>  
>
> Yes.. There are many reasons why I strongly believe duration is
> preferable to end:
>
>  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).
>     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:
>      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.
>     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).
>
>  
>
> 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
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743

---

From: Garry Shutler <[email-masked]>
Date: Fri, 15 Feb 2019 09:44:47 +0000

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 <[email-masked]> wrote:

> 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.
>
> but iCalendar and most implementations allow tasks to have a due date only.
> And that's mostly what an average user cares about.
>
> 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).
>
>
>
> 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.
>
> *Von:* calsify <[email-masked]> <[email-masked]> *Im
> Auftrag von *Neil Jenkins
>    - It simplifies translation of VEVENTs with DTSTART/DTEND from
>    iCalendar.
>
>
>
>    - It allows to specify recurring events with a fixed end time even in
> 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.
>
>
>
> The UI is independent of the underlying data format; as mentioned above
> you need to be able to translate between the two anyway.
>
>
>
>    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:
>       this would then also work for recurrences, which there is no solution for
>       in iCalendar.
> 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
> 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 [email-masked]://www.ietf.org/mailman/listinfo/calsify
>
> --
> Marten Gajda
> CEO
>
> dmfs GmbH
> Schandauer Straße 34
> 01309 Dresden
> GERMANY
>
> phone: +49 177 4427167
> email: [email-masked]
>

---

From: "Alexander Nimmervoll" <[email-masked]>
Date: Fri, 15 Feb 2019 13:56:16 +0100

Are the use cases really so different between events, meetings and tasks regarding time? Meetings, flights, concerts and various events also can have an estimated/scheduled duration different to actual duration. Similar for start and end time.

So a data model which implements a standard property/parameter to distinguish between estimated/scheduled and actual start/end/duration could be useful for events and tasks in my opinion.

Cheers,
Alex

Von: calsify <[email-masked]> Im Auftrag von Garry Shutler
Gesendet: Freitag, 15. Februar 2019 10:45
An: [email-masked]
Betreff: Re: [calsify] JSCalendar duration vs. end time

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

---

From: Michael Douglass <[email-masked]>
Date: Fri, 15 Feb 2019 11:11:17 -0500

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.

-
> On Fri, 15 Feb 2019 at 09:08, Marten Gajda <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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.
>>
>     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.
>
>>     *Von:*calsify <[email-masked]>
>>     <mailto:[email-masked]> *Im Auftrag von *Neil Jenkins
>>     *An:* [email-masked] <mailto:[email-masked]>
>>     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.
>>
>>         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.
>>
>>      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:
>>          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.
>>         duration should remain fixed and the end should shift (e.g.
>>         for flights).
>>
>>     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.
>>
>>
>>     [email-masked]  <mailto:[email-masked]>
>     email:[email-masked]  <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Tim Hare" <[email-masked]>
Date: Mon, 18 Feb 2019 17:59:06 -0500

I am not a developer at the moment, but an interested party.  I’m more interested, for my part, in enabling people and organizations to publish calendar information easily.  

That said, in my opinion anything that causes divergence between RFC 5545 and representations in other ways (XML, JS) can be problematic.  I’m on record as wondering why property parameters didn’t become XML attributes, because that representation seemed to match the text-only representation better;   I believe JSCalendar should make it easy to go from DTSTART/DTEND to a start time and end time  and from DTSTART/DURATION to start time and duration.   There may be non-user-facing instances where translating between one representation and another is useful, and being able to ‘round trip’ it makes development of such things a little less bug-prone.

Tim Hare
Interested Bystander, Non-Inc.

From: calsify [mailto:[email-masked]] On Behalf Of Michael Douglass
Sent: Friday, February 15, 2019 11:11 AM
To: [email-masked]
Subject: Re: [calsify] JSCalendar duration vs. end time

-

Garry Shutler

 

On Fri, 15 Feb 2019 at 09:08, Marten Gajda <[email-masked] <mailto:[email-masked]> > wrote:

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).

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.

Cheers,

Marten

Cheers,

Alex

Von: calsify  <mailto:[email-masked]> <[email-masked]> Im Auftrag von Neil Jenkins
Gesendet: Freitag, 15. Februar 2019 00:20
An: [email-masked] <mailto:[email-masked]> 
Betreff: Re: [calsify] JSCalendar duration vs. end time

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. 

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:

Neil.

-- 
Marten Gajda
CEO
 
dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY
 
phone: +49 177 4427167
email: [email-masked] <mailto:[email-masked]>