CalendarEvent Duration

21 views

Skip to first unread message

Tom Smith

unread,

Sep 6, 2016, 8:31:56 PM9/6/16

to JMAP

The recent changes to CalendarEvent no longer include the ability to return the end date of an event. What does this mean when parsing DTSTART/DURATION and DTEND from iCalendar?

If we have a DTSTART and DTEND and no DURATION, is the intention that the JMAP server calculate the duration between these?. This means the client will ultimately need to calculate it's own end date again. When saving a modified event, should the JMAP server save only DTSTART and DURATION?

Also, if we have DTSTART/DTEND and DURATION, do we ignore DURATION and calculate, or use DURATION?

Kind Regards,

Tom.

Neil Jenkins

unread,

Sep 9, 2016, 9:55:41 AM9/9/16

to JMAP Mailing List

On Wed, 7 Sep 2016, at 10:31 AM, Tom Smith wrote:

The recent changes to CalendarEvent no longer include the ability to return the end date of an event. What does this mean when parsing DTSTART/DURATION and DTEND from iCalendar?

It means that you calculate the duration from the DTSTART/DTEND and use this in the event (just as before you would have had to work out the DTEND if the iCalendar version had a DURATION).

This means the client will ultimately need to calculate it's own end date again.

Whereas before the client would have had to calculate the duration. Either way the client will have to do a bit of date maths, but it's not hugely difficult.

When saving a modified event, should the JMAP server save only DTSTART and DURATION?

An iCalendar version may be saved with either DURATION or DTEND.

Also, if we have DTSTART/DTEND and DURATION, do we ignore DURATION and calculate, or use DURATION?

As per the definition of the VEVENT component, either 'dtend' or 'duration' MAY appear in a 'eventprop', but 'dtend' and 'duration' MUST NOT occur in the same 'eventprop'. So the result is undefined in iCalendar, therefore there is no correct answer here. Either option seems reasonable.