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

From: "Robert Stepanek" <[email-masked]>
Date: Thu, 06 Jun 2019 16:56:21 +0100

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

---

From: "Robert Stepanek" <[email-masked]>
Date: Mon, 17 Jun 2019 18:14:54 +0200

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

---

From: Daniel Migault <[email-masked]>
Date: Mon, 17 Jun 2019 16:17:58 +0000

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 <[email-masked]> On Behalf Of Robert Stepanek
Sent: Monday, June 17, 2019 12:15 PM
To: [email-masked]
Subject: Re: [calsify] JSCalendar: alternative to current all-day events

Cheers,
Robert

Currently:

  *   Any other event:

Alternative:

Cheers,
Robert

_______________________________________________
calsify mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/calsify

---

From: "Robert Stepanek" <[email-masked]>
Date: Mon, 17 Jun 2019 18:22:56 +0200

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. I will update the latter in the next few days.

Cheers,
Robert

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

---

From: Andri Möll <[email-masked]>
Date: Mon, 17 Jun 2019 17:44:00 +0000

> 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:
> 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
>
>> 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
>>
>>
>> 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
>>
>>
>>   * 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.
>>     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.
>>
>>
>>           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.
>>
>>       * 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.
>>           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
>>
>>
>>     [email-masked] <mailto:[email-masked]>
>>

---

From: Marten Gajda <[email-masked]>
Date: Mon, 17 Jun 2019 23:48:41 +0200

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

>> <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-icalendar>
>> I will update the latter in the next few days.
>>
>> Cheers,
>> Robert
>>
>>> 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
>>>     In both cases, developers thought to use the isAllDay property
>>>     to express a user intention, but came they learn they couldn't.
>>>
>>>      
>>>
>>>       * The start, duration, timeZone properties and their
>>>         recurrence overrides can all can be defined independently.
>>>         The recurrenceRule{until} property also can be defined
>>>         independently.

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

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

---

From: Marten Gajda <[email-masked]>
Date: Tue, 18 Jun 2019 00:04:11 +0200

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

>   * 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
>>   * 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.
>>
>>
>>   * 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.
>>       o an event with zero time in start, duration, until and no time
>>         zone will be converted DATE value types

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

---

From: Doug Royer <[email-masked]>
Date: Mon, 17 Jun 2019 17:16:28 -0600

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

And add a description of "all day", because it is not "all day".

Is it you want it to be marked on the calendar, but be free time?

-- 

Doug Royer - (http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: Doug Royer <[email-masked]>
Date: Mon, 17 Jun 2019 17:25:37 -0600

"Indicates whether this event is meant to represent an all-day event,
    and SHOULD be presented accordingly in a calendaring application.
    The value of this property is independent of the actual time-span
    covered by this event."

So, an isAllDay could as an example, be 36 or more hours long?

--

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 18 Jun 2019 10:39:48 +1000

> So, an isAllDay could as an example, be 36 or more hours long?

It certainly could. This is already very possible with iCalendar, e.g. this event here:

BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
PRODID:-//FastMail/1.0/EN
BEGIN:VEVENT
CREATED:20190219T071436Z
DTEND;VALUE=DATE:20190608
DTSTAMP:20190219T071436Z
DTSTART;VALUE=DATE:20190603
SEQUENCE:0
SUMMARY:CalConnect Bedford
TRANSP:TRANSPARENT
UID:xxx
END:VEVENT
END:VCALENDAR

Which is an "all day event" with a duration of 5 days.

Bron.
--
 Bron Gondwana, CEO, FastMail Pty Ltd
 [email-masked]

---

From: "Neil Jenkins" <[email-masked]>
Date: Tue, 18 Jun 2019 13:15:59 +1000

On Fri, 7 Jun 2019, at 01:56, Robert Stepanek wrote:
> 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.

Suppose I have such an event (24h long, starts at midnight on 1st Jan 2020 in Australia/Melbourne). It is unclear to me what I should show the user if their time zone is different (e.g. I view the calendar in Europe/London); does it show up in the "all day" section on both 31st Dec and 1st Jan? That's the only sensible thing I can come up with. But that would give the impression the event happens over two days, which is incorrect. (But perhaps the issue here is really more that the birthday should not have been given a time zone.)

I agree the name could perhaps be better. `showWithoutTime` perhaps? And a description something like:

*Indicates the time is not important to display to the user when rendering this event, for example an event that conceptually occurs all day or across multiple days, such as "New Year's Day" or "Italy Vacation". While the time component is important for free-busy calculations and checking for scheduling clashes, calendars may choose to omit displaying it and/or display the event separately to other events to enhance the user's view of their schedule.*

I also agree we want this for JSTask. For example you might set a *due* of `2019-06-30T23:59:59` , i.e. the task deadline is by the end of 30 June. Most UIs would probably just want to show *Due: 30 June*, but it would make sense to have this explicitly stated on the JSTask object so you could signal when the time truly was important.

Neil.

---

From: "Robert Stepanek" <[email-masked]>
Date: Tue, 18 Jun 2019 13:55:33 +0200

> Suppose I have such an event (24h long, starts at midnight on 1st Jan 2020 in Australia/Melbourne). It is unclear to me what I should show the user if their time zone is different (e.g. I view the…

I also wouldn't set a timezone on my birthday, but there's been a number of people at last CalConnect reporting that this actually is what users do. I don't have a good answer how to render that if the event timezone and UI timezone don't match - probably a calendaring UI should just ignore the "isAllDay" property if the timezones of the UI and event don't match.

> I agree the name could perhaps be better. `showWithoutTime` perhaps? And a description something like:

That's fine for me as well. I chose "isAllDay" rather than "showAsAllDay", because I figured that "show" implies a graphical user interface, which might not be adequate in all cases (think: calendar applications for visual impaired). But I'm not too vested in it.

> I also agree we want this for JSTask. 

Yeah, there's several people now asking for it, so I guess I shouldn't have removed it in the first place. But it's great we got that established :)

---

From: Doug Royer <[email-masked]>
Date: Tue, 18 Jun 2019 11:50:38 -0600

> It certainly could.  This is already very possible with iCalendar, e.g. 
(example not included)
> Which is an "all day event" with a duration of 5 days.

So, with, or without 'isAllDay' they mean EXACTLY the same thing. What 
is the point of 'isAllDay' when with or without it, it means the same thing?

If I am incorrect, what does it mean?

--

---

From: Michael Douglass <[email-masked]>
Date: Tue, 18 Jun 2019 15:26:06 -0400

Putting aside the  exact representation for the moment there is a need - 
expressed by calendar users - to represent what they mean by "all day".

For birthdays etc the current date-only is probably fine (though 
possibly being able to flag these as anniversary events might be useful).

However, for public and social events things are different. These are 
generally known as 'all day' - the start and end may be ill-defined if 
at all. They also often take place in a specific timezone.

For years creators of ics files have been trying to put timezones on 
dates. I tell them they can't - they say why? The only answer is that 
the standard says so. They want to flag an all day event as taking place 
in a certain timezone. Setting the start and end to midnight doesn't 
have the same meaning - that is a 24hour event.

The uis for public calendars need to know the difference between a true 
24hour event and an all-day event in a certain timezone - we display 
them differently.

So I think the first issue is to decide whether our users are simply 
being unreasonable or if they have a genuine unfulfilled need.

If you want an analogy - we can either see where people walk and then 
lay down the paths or we can lay the paths and forever repair the grass.

---

From: Doug Royer <[email-masked]>
Date: Tue, 18 Jun 2019 15:13:06 -0600

Great - It needs to be documented in the spec.

If it means fuzzy dtstart/duration, that's fine. But say so.
Does it mean "no earlier than dtstart" and "no longer than duration"?
Without knowing, what will get displayed will be different across 
implementations. So far, I would just ignore it, as it has no specific 
meaning yet.

So, not sure what you mean when you say:

   "For years creators of ics files have been trying to put timezones on
   dates. I tell them they can't - they say why? The only answer is that
   the standard says so. They want to flag an all day event as taking
   place in a certain timezone. Setting the start and end to midnight
   doesn't have the same meaning - that is a 24hour event."

So, don't set them to midnight. If you mean Anniversary events, they 
are date-only. That has nothing to do with all day. An anniversary is 
'on that date', not 'all day'. Those can be localtime or TZ specific, 
and may or might not have a dtend/duration.

TZ is not required, and *is* allowed on Date-Time and Date events.

	DTSTART;TZID=America/New_York;VALUE-DATE:19980119

and
	DTSTART;TZID=America/New_York:19980119T020000

and
	DTSTART:19980119T020000

Are all valid. Timezones are *not* required on the events. So users do 
not need a timezone in an ics file. When omitted, those are localtime 
(like new years day and birthdays). So isAllDay does not need to exist 
to specify those.

When you say: "The uis for public calendars need to know the difference 
between a true 24hour event and an all-day event in a certain timezone - 
we display them differently."

I am guessing that a 'uis' is a CUA?

Exactly how will they be displayed differently? An anniversary may 
display differently (it can have no duration). But any other 
start/duration event simply takes up the time on the CUA like any other.

Still confused by "all day" vs any other event that may or might not be 
24-hours in duration.

--

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 19 Jun 2019 11:20:49 +1000

> DTSTART;TZID=America/New_York;VALUE-DATE:19980119

Do you have a citation to support this statement?

Mike and I are basing our understanding from reading RFC 5545: Section 3.2.19

      The "TZID" property parameter MUST NOT be applied to DATE
      properties and DATE-TIME or TIME properties whose time values are
      specified in UTC.

It does is somewhat fuzzy langauge, but our impression at CalConnect the other week when we look at this was that RFC5545 prohibits the use of TZID with VALUE=DATE.

Regards,

Bron.

---

From: "Neil Jenkins" <[email-masked]>
Date: Wed, 19 Jun 2019 14:28:25 +1000

> Great - It needs to be documented in the spec.

Yes, I have suggested text in a previous email in this thread.

> Exactly how will they be displayed differently?

I suggest try using a common CUA such as Outlook, Google Calendar, Apple Calendar. These all have an option to mark an event as "all day" (this is literally the term normally used in the interface), which causes the client to display it separate to timed events in the spatial view (e.g. Day, Week view) of the calendar.

When storing in iCalendar format, clients distinguish these events by using the DATE format rather than the DATETIME format. In JSCalendar we are using an explicit boolean property instead, which we believe is better aligned with developers' mental model and is easier to implement.

This particular thread is discussing loosening some current restrictions, designed to ensure a 1:1 mapping to iCalendar, to allow more representation of data not currently possible in iCalendar (which some developers have expressed a wish for in their applications).

Neil.

---

From: Doug Royer <[email-masked]>
Date: Tue, 18 Jun 2019 23:04:48 -0600

>        properties and DATE-TIME or TIME properties whose time values are

That is because UTC (Z) is a time zone. It has nothing to do with all 
day or anniversary. A 'Z' in addition to a TZID would be placing two 
time zones into the same property. That would be nonsensical.

> It does is somewhat fuzzy langauge, but our impression at CalConnect the 
> other week when we look at this was that RFC5545 prohibits the use of 
> TZID with VALUE=DATE.

The ABNF does not exclude TZID with VALUE=DATE. I can not find anything 
that does. It is not excluded in DTSTART, DUE, DTEND, RECURRENCE-ID, 
EXDATE, or RDATE. All of their ABNF allows for it.

--

---

From: Doug Royer <[email-masked]>
Date: Tue, 18 Jun 2019 23:23:33 -0600

On 6/18/19 10:28 PM, Neil Jenkins wrote:

> I suggest try using a common CUA such as Outlook, Google Calendar, Apple 
> Calendar. These all have an option to mark an event as "all day" (this 
> is literally the term normally used in the interface), which causes the 
> client to display it separate to timed events in the spatial view (e.g. 
> Day, Week view) of the calendar.

Yes, my question was as defined in the spec. And the fact that its usage 
is not consistent. Some apps give 'all-day' events with a 1 hour 
duration (or maybe it is the default event duration set by the user 
settings). Some have no DTEND (anniversary).

> When storing in iCalendar format, clients distinguish these events by 
> using the DATE format rather than the DATETIME format. In JSCalendar we 
> are using an explicit boolean property instead, which we believe is 
> better aligned with developers' mental model and is easier to implement.

I can not find an RFC that defines 'all day' events. Just anniversaries 
which some use to mean 'all day'.

> This particular thread is discussing loosening some current 
> restrictions, designed to ensure a 1:1 mapping to iCalendar, to allow 
> more representation of data not currently possible in iCalendar (which 
> some developers have expressed a wish for in their applications).

I still do not understand the concept of 'all-day' that is not really 
'all-day'. Do people really mean anniversary or day (daily) reminder?

When I check 'all day' on my google calendar, it removes DTEND, which 
makes it an anniversary type event. Then shows it consumes exactly 
24-hours when I get a summary of events. On the calendar itself, it 
shows zero duration. The google android calendar app seem to do the same 
thing.

Thunderbird keeps DTEND making it equal to DTSTART and takes away the 
TIME value from DTSTART and DTEND (making it VALUE=DATE - WITH a time 
zone). And views as a 0 seconds duration event on the user interface. 

So, looking at what I have, there is no consistent meaning for all-day.
--

---

From: "Robert Stepanek" <[email-masked]>
Date: Wed, 19 Jun 2019 10:40:43 +0200

> time zones into the same property. That would be nonsensical.

We read
 'The "TZID" property parameter MUST NOT be applied to DATE properties'
as
 'The TZID property parameter MUST NOT be applied to properties *with value type* DATE'.

Regards,
Robert

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 19 Jun 2019 10:20:40 -0400

Hi Robert,

>  'The TZID property parameter MUST NOT be applied to properties *with

Yes, but let me quote the whole sentence here because there is a slight 
problem with it:

I think there is a comma missing here! There ought to be a comma after 
"DATE properties", which would make it clear that the whose clause applies 
to DATE-TIME and TIME only. i.e., the correct interpretation of this using 
parenthesis to group terms properly is:

    TZID MUST NOT be applied to either (DATE value properties) or 
((DATE-TIME or TIME) properties whose time values are
          specified in UTC)

I think the missing comma is a minor infraction, but one that could be 
fixed via an erratum if needed. In any case I think your further 
clarification of adding "with value type" is correct and could also be part 
of the erratum.

Even if one were not to agree with that, at best all that could be said is 
that 5545 does not define how TZID is interpreted when applied to a DATE 
value property. In all likelihood it would not be interoperable. I would 
guess that many iCalendar libraries might simply ignore it and not round 
trip it since they will likely use platform specific classes for date and 
date-time representation

-- 
Cyrus Daboo

---

From: Doug Royer <[email-masked]>
Date: Wed, 19 Jun 2019 09:28:53 -0600

On 6/19/19 8:20 AM, Cyrus Daboo wrote:

> Even if one were not to agree with that, at best all that could be said 
> is that 5545 does not define how TZID is interpreted when applied to a 
> DATE value property. In all likelihood it would not be interoperable. I 
> would guess that many iCalendar libraries might simply ignore it and not 
> round trip it since they will likely use platform specific classes for 
> date and date-time representation
> 

In the ISO standard ISO.8601.2004 referred to in 5545, you can use 
200004 to mean 1-April of 2000. It also allows for 20000401T01 to mean 
1am (0 minutes 0 seconds) on 1-April of 2000.

I no longer have the pay to see ISO standard. I do have my notes from my 
old code. My notes indicate that omitted values are the same as the 
first valid value for the omitted data
(as in 20000101 == 20000101T000000).

Does someone have ISO.8601.2004?

As to date-time classes, the ones I have looked at in the past, they 
default to zeros for values. So 20010101 is the same as 20000101T000000 
in those implementations. Maybe that is why it has not been noticed before.

They also default to zero for month and day of month. I suspect no one 
uses that feature and the implementations use and set at least year, 
month, and day.

They seems to work maybe because they default to 0 hours, 0 minutes, and 
0 seconds with their comparison operators.

The ICU date-time libraries also know the difference between a date and 
date time value, an can compare between them.

NOTE that the WWW also treats omitted values the same a default value.

See https://www.w3.org/TR/NOTE-datetime

   "Examples

    1994-11-05T08:15:30-05:00 corresponds to November 5, 1994, 8:15:30
    am, US Eastern Standard Time.

    1994-11-05T13:15:30Z corresponds to the same instant."

For which I read that as also with omitted time.

--

---

From: Michael H Deckers <[email-masked]>
Date: Wed, 19 Jun 2019 17:49:30 +0000

On 2019-06-19 15:28, Doug Royer asked:
> I no longer have the pay to see ISO standard. I do have my notes from 
> my old code. My notes indicate that omitted values are the same as the 

    ISO 8601:2004 used to be free for a while, so I can send
    you a pdf (239 kB) copy privately.

    Note however that a new standard ISO 8601:2019 in two parts
    (8601-1 and 8601-2) is in force since 2019-02. The first part
    is more or less the same as the old ISO 8601:2004 and is
    available online in a pirate version at
    [http://biaozhun.doc88.com/p-8751736368436.html].
    The second part also used to be available on this site, but
    I cannot find it right now.

    Anyway, in the new ISO 8601:2019, dates without time may well
    have a time zone offset, but only in the new explicit format,
    like:
             2019Y06M19DZ+02H
    In the implicit format 2019-06-16, time zone offsets are still
    not allowed.

    HTH.

    Michael Deckers.

---

From: Michael H Deckers <[email-masked]>
Date: Wed, 19 Jun 2019 21:42:49 +0000

>    have a time zone offset, but only in the new explicit format,

    This example is wrong -- the positive sign is not
    allowed in extended format, so that one must write
             2019Y06M19DZ02H
    (String comparison of two extended format datetime
    notations without leading zeroes yields a strict semantic
    comparison.)

    Sorry.
    Michael Deckers.

---

From: Michael Douglass <[email-masked]>
Date: Fri, 21 Jun 2019 23:36:07 -0400

On 6/17/19 18:04, Marten Gajda wrote:
> 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.
> email:[email-masked]

---

From: Doug Royer <[email-masked]>
Date: Sat, 22 Jun 2019 14:23:34 -0600

On 6/18/19 5:55 AM, Robert Stepanek wrote:
>>> 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.
>>
>> Suppose I have such an event (24h long, starts at midnight on 1st Jan 
>> 2020 in Australia/Melbourne). It is unclear to me what I should show 
>> the user if their time zone is different (e.g. I view the calendar in 
>> Europe/London); does it show up in the "all day" section on both 31st 
>> Dec and 1st Jan? That's the only sensible thing I can come up with. 
>> But that would give the impression the event happens over two days, 
>> which is incorrect. (But perhaps the issue here is really more that 
>> the birthday should not have been given a time zone.)
> 
> I also wouldn't set a timezone on my birthday, but there's been a number 
> of people at last CalConnect reporting that this actually is what users 
> do. I don't have a good answer how to render that if the event timezone 
> and UI timezone don't match - probably a calendaring UI should just 
> ignore the "isAllDay" property if the timezones of the UI and event 
> don't match.

Per 5445, that means they are in local time. That is to be displayed 
using your display time zone.

Which is interesting on web user interfaces x-hosted back from another 
time zone. I have servers in both Mountain and Central time zones. When 
I remotely display a local time event, they are 1 hour different than 
each other - as it should be.

You could mark your birthday as defined by the UTC time you were born. 
In that case set the TZID to the TZID of your birth location, date, and 
time. In which case you set TZID  (without Z), or set the UTC time (Z) 
and do not use a TZID.

Most people celibate their birthday on the date in local time.
In which case you set the DTSTART and do not use TZID or (Z). If you 
travel across the international date line, do you want your 
reminder/anniversary on the date specified that you are in? Or up to 
24-hours offset and seemingly wrong?

The purpose of 5445 and hopefully bis, is to define the data and what it 
means.

It sounds like a user interface guide should be written that explains or 
suggests how to represent the data to a user across vendors so it is 
consistently understood by the average user.

It appears to me that checking 'all-day' on google and Thunderbird, make 
a floating time anniversary VEVENT. They do not seem to allow the user 
to make other versions of anniversary.

With Thunderbird, when I click 'All day Event', it grays out the time.
Set the start equal to end, and mails out:

DTSTART;VALUE=DATE:20190628
DTEND;VALUE=DATE:20190629

GOOGLE:

DTSTART;VALUE=DATE:20190628
DTEND;VALUE=DATE:20190629

Same thing. Both call 'All-Day' to be a anniversary with floating time.
No special iCalendar tag needed.

*AND* both when they get a anniversary  with floating time VEVENT, 
automatically check 'All Day' on their user interfaces. Again no
special iCalendar tag needed.

>>
>> I agree the name could perhaps be better. |showWithoutTime| perhaps? 
>> And a description something like:

That already exists.

To have an iCalendar object without time, per 5545:
  "...For cases where a "VEVENT" calendar component
      specifies a "DTSTART" property with a DATE-TIME value type but no
      "DTEND" property, the event ends on the same calendar date and
      time of day specified by the "DTSTART" property. ..."

Because 5545 says:
"...For cases where a "VEVENT" calendar component
     specifies a "DTSTART" property with a DATE value type but no
     "DTEND" nor "DURATION" property, the event's duration is taken to
     be one day. ..."

The only way (and the only way needed), is to specify a VEVENT with

Floating time:
	DTSTART;...;YYYYMMDDTHHMMSS

or for non-floating time.
	DTSTART;...TZID=aTz:YYYYMMDDTHHMMSS
or
	DTSTART;...:YYYYMMDDTHHMMSSZ

> That's fine for me as well. I chose "isAllDay" rather than 
> "showAsAllDay", because I figured that "show" implies a graphical user 
> interface, which might not be adequate in all cases (think: calendar 
> applications for visual impaired). But I'm not too vested in it.

Or process based events that are acted on - like a sequence of events 
like Alexa or Google home.

> Yeah, there's several people now asking for it, so I guess I shouldn't 
> have removed it in the first place. But it's great we got that 
> established :)

They already exist in iCalendar. It is the user interfaces that omit them.

--