Re: [calsify] JSCalendar duration vs. end time

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

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