Re: [calsify] JSCalendar: alternative to current all-day events

Thanks Robert for the clarification. If there are any other point to discuss or that are raising concerns, please let us know as we are close to move the document forward.
Yours,
Daniel

From: calsify <calsify-bounces@ietf.org> On Behalf Of Robert Stepanek
Sent: Monday, June 17, 2019 12:15 PM
To: calsify@ietf.org
Subject: Re: [calsify] JSCalendar: alternative to current all-day events

I have uploaded RFC draft version 15 which now includes the proposed changes. I chose to keep the name "isAllDay" for the property, rather than renaming it to "showAsAllDay". I also removed the "isAllDay" property entirely from the JSTask object.

See https://tools.ietf.org/html/draft-ietf-calext-jscalendar-15#section-5.1.4

>From my initial analysis, the mapping to iCalendar is rather simple:

  *   If the JSEvent timeZone is null, the start time has zero time, and the duration is a multiple of days or weeks, then DTSTART is of type DATE. In this case, clip off any non-zero time from the recurrence rule "until" property.
  *   Otherwise map "start" to a DTSTART of type DATE-TIME.
  *   I also consider using a new iCalendar boolean property IS-ALL-DAY to cleanly map "isAllDay".

I will update the informational iCalendar mapping guideline accordingly.

Cheers,
Robert

On Thu, Jun 6, 2019, at 5:56 PM, Robert Stepanek wrote:
One of the repeatedly discussed topics in JSCalendar is how to model all-day events.

Specifically, variants of the following uses repeatedly come up, where the current JSCalendar model seems not to be adequate:

  *   Calendar users create an event starting e.g. 8am and ending 7pm, but want to view this an all-day event in their UI. The current model misses a flag to express this, as the isAllDay property is not appropriate to indicate the user intention.
  *   Calendar users want to set their calendar on their birthday, when they only would like to set it for the complete day in their usual time zone. They still want it to show up as an all-day event in their UI.

In both cases, developers thought to use the isAllDay property to express a user intention, but came they learn they couldn't.

This is reason enough to revisit that part of the specification and discuss alternatives.

Currently:

  *   Any event MUST define a start property value in the form "YYYY-MM-DDTHH:MM:SS[.DIGITS]"
  *   An all-day event:

     *   MUST have the isAllDay property set to "true"
     *   MUST NOT have a non-zero time in the start and duration property values
     *   MUST NOT define a time zone

  *   Any other event:

     *   MUST have the isAllDay property set to "false"
     *   MAY define non-zero time  in start, duration
     *   MAY set a timeZone.

  *   This allows to model iCalendar DATE, local DATE-TIME, floating DATE-TIME, UTC DATE-TIME.

Alternative:

  *   The isAllDay boolean property gets removed.
  *   A new showAsAllDay boolean defines how the user intends to view this event. Setting this property does not have any implications on the allowed values in the event time properties.
  *   The start, duration, timeZone properties and their recurrence overrides can all can be defined independently. The recurrenceRule{until} property also can be defined independently.
  *   It is up to implementations to convert this time model to iCalendar. Most probably:

     *   an event with zero time in start, duration, until and no time zone will be converted DATE value types
     *   an event with no time zone will be converted to a local DATE-TIME without TZID
     *   otherwise it will be a DATE-TIME with TZID or UTC DATE-TIME

What do you think? Did we miss something?

Cheers,
Robert

_______________________________________________
calsify mailing list
calsify@ietf.org<mailto:calsify@ietf.org>
https://www.ietf.org/mailman/listinfo/calsify