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

[Michael Douglass <[e-mail]>]

On 6/17/19 18:04, Marten Gajda wrote:
>
>
> 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?
>
Absolutely - Thursday is take out the garbage sometime during the day - 
I generally need to be reminded all day. I don't see why tasks are any 
different in this respect.
>
> 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
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify