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

[Marten Gajda <[e-mail]>]

Hi Andri,

Am 17.06.19 um 19:44 schrieb Andri Möll:
>
>> 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?
>
Indeed we've been talking about this and there was mostly consensus in
that a date type (as used in iCalendar) encodes two things:

* value: a point in (local) time, i.e. midnight (the start) of that
particular day
* presentation: show as all-day

These are, however, two unrelated things. "all-day" is really just a UI
issue and has no effect on the calendar math. Aside from the
presentation, an all-day event is the same as an event which explicitly
starts at midnight and has a duration of full days. There are even use
cases when you might want to present an event like an "all-day" event
even though it doesn't have a duration of full days or even though it
may not start or end at midnight.

Also, sometimes, the date type falsely suggests an interpretation as a
range (midnight to midnight). I've seen discussions on whether a
date-type EXDATE would cancel all/any occurrences of a recurring
date-time event on that day.

In addition:

DTSTART:20190617

is the implicit form. It implies a time component of 00:00:00 and a
presentation as all-day event, whereas

start: 2019-06-17T00:00:00
isAllDay: true

is the explicit form. Both properties are explicitly stated.

>  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.
>
This is actually a perfect example for why the implicit date type is a
bad idea and why the explicit form of JSCalendar is much better. You
have to make sure *all* preconditions (implications) are met before you
can use the implicit form. This is not an issue with the explicit form
and it's not a problem of JSCalendar (the problem is iCalendar).

JSCalendar is supposed to be the successor of iCalendar and to fix some
its well known issues. This is one of them. Eventually JSCalendar will
replace iCalendar and the conversion won't be necessary anymore. A
correct data model has a higher priority than the conversion to legacy
formats.

> 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?
>
I have no strong feelings on this particular issue. Given that, in the
current spec, *all* date values have a time component there is no need
to emphasize this fact again in the name of the type. On the other hand
I wouldn't mind if these were called "UTCDateTime" and "LocalDateTime".

Cheers,

Marten

> 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
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: [phone]
email: [e-mail]

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743