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

[Andri Möll <[e-mail]>]

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

This probably got covered early in JSCalendar's life, so apologies for 
bringing it up again, but how did JSCalendar end up with no date type? 
The above sounds like a error prone and complicated heuristic approach 
to something that should just be explicit. Why didn't JSCalendar include 
a date type for events with dates and keep the time type for events with 
times? I'm willing to take bets there will be implementations that miss 
the "timeZone is null" clause and accidentally truncate timed events 
with nominal durations.

And while on the subject, isn't calling the date-time formats `UTCDate` 
and `LocalDate` 
(https://tools.ietf.org/html/draft-ietf-calext-jscalendar-15#section-3.2.1) 
slightly misleading given they're date-times?

On 6/17/19 4:22 PM, Robert Stepanek wrote:
> Hi Daniel,
>
> I am not aware of any open points, the draft includes all feedback we got.
>
> I suggest to move this document forward, irrespective of its 
> accompanying informational RFC 
> https://tools.ietf.org/html/draft-ietf-calext-jscalendar-icalendar. 
> <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-icalendar> I 
> will update the latter in the next few days.
>
> Cheers,
> Robert
>
> On Mon, Jun 17, 2019, at 6:18 PM, Daniel Migault wrote:
>>
>> 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 <[e-mail]> *On Behalf Of *Robert Stepanek
>> *Sent:* Monday, June 17, 2019 12:15 PM
>> *To:* [e-mail]
>> *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:
>>
>>           o MUST have the isAllDay property set to "true"
>>           o MUST NOT have a non-zero time in the start and duration
>>             property values
>>           o MUST NOT define a time zone
>>
>>       * Any other event:
>>
>>           o MUST have the isAllDay property set to "false"
>>           o MAY define non-zero time  in start, duration
>>           o 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:
>>
>>           o an event with zero time in start, duration, until and no
>>             time zone will be converted DATE value types
>>           o an event with no time zone will be converted to a local
>>             DATE-TIME without TZID
>>           o 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
>>
>>     [e-mail] <mailto:[e-mail]>
>>
>>     https://www.ietf.org/mailman/listinfo/calsify
>>
>>
>>
>
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify