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

[Marten Gajda <[e-mail]>]

Am 17.06.19 um 18:14 schrieb Robert Stepanek:
> I also removed the "isAllDay" property entirely from the JSTask object.

Hmm ... I see how "isAllDay" doesn't really apply to a task, but it
would be nice to have a way to express this kind of fussiness for start
and/or due dates in cases when the actual time is not that important (or
even unknown). Always terminating tasks on a specific time can give a
false sense of accuracy which might not exist. Sometimes you just want
to express "at some time throughout that day". Does that make sense?

Marten

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