Re: [calsify] JSCalendar duration vs. end time

["Bron Gondwana" <[e-mail]>]

On Fri, Feb 15, 2019, at 05:25, Alexander Nimmervoll wrote:
> 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.



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.

Obviously client UI considerations are important. Just checking Google's UI, it shows both a duration and an end time - and if you create something with an odd start time (like 5 minutes past the hour) it proposes end times based on the duration rather than by the end time:




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



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!

>  


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


>  



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
 [e-mail]