Subject: [calsify] Z, UTC, DATE, DATE-TIME, comparing and clarification

From: Doug Royer <[email-masked]>
Date: Fri, 21 Jun 2019 15:21:33 -0600

Statement of what I think is fact, and a proposal for future documentation.

I think the following are true in iCalendar and should be specifically 
documented:

(A) That when 'Z' is appended to date-time value, it is shorthand for:

	TZID=UTC:YYYYMMDDTHHMMSS

     It is also currently valid and acceptable. Because a time zone FOO
     could exist now or in the future that is equivalent to UTC.

(B) For the purpose of comparison specifically declare that:

	YYYYMMDDT000000

     is the same value as:

	YYYYMMDD

(C) The existing 5545 text:

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

     Means do not do this:
	
	...TZID=notZtz;VALUE=DATE-TIME:YYYYMMDDTHHMMSSZ

     And do not to this:

	...TZID=UTC;VALUE=DATE-TIME:YYYYMMDDTHHMMSSZ

     And I think the text should changed to be:

	"The "TZID" property parameter MUST NOT be applied to date or
	date-time property values whose values are already specified in
	UTC."

     Because it is nonsensical when YYYYMMDDTHHMMSSZ also has a TZID not
     equal to UTC (Z).

     Or duplicated when a TZID=UTC is added to a UTC property value
     specified in Z (UTC).

(D) Issues / questions:

Can existing implementations compare DATE to DATE-TIME values? If yes, 
then they are treating the TIME part of a DATE value as 00:00:00 - 
correct? So, I don't see how my above declarations would effect any code.

If an implementation can not currently compare DATE to DATE-TIME values,
then nothing should be effected. Not sure how they sort items on the 
calendar.

Do current implementations ignore TZID on VALUE=DATE properties of 
YYYYMMDD? or do they treat it as if it were:
  "...;TZID=DATE-TIME:YYYYMMDDT000000"

If a current implementation wants to declare a DATE value in UTC, then 
currently it must use the format ....;TZID=UTC:HHMMSS, as the ABNF does 
not allow for 'Z' on a DATE value, and does allow a TZID parameter, that 
might be 'UTC'. Which is the equivalent of YYYYMMDDZ.

The only two things controversial is:

(1) YYYYMMDD == YYYYMMDDT0000. For which I see no problem.

And (2) ...TZID=tzid;VALUE=DATE:YYMMDD is valid, because the ABNF 
currently allows for it is all properties that allow date/date-time 
property values. And that it is possible for TZID=UTC in those cases.

And 5545 says:  "... This ABNF is required for
    the implementation of parsers and to serve as the definitive
    reference when ambiguities or questions arise in interpreting the
    descriptive prose definition of the memo. Additional restrictions
    that could not easily be expressed with the ABNF syntax are specified
    as comments in the ABNF...."

And TZID is not excluded in the ABNF or comments in the ABNF for DATE 
values.

If this WG wants them excluded, it should be explicitly decided and 
declared in the ABNF of the release of 5545 bis.

Calconnect is great for finding issues, however, it is not the platform 
for making IETF decisions or declarations. Those must take place on the 
appropriate IETF mailing list.

-- 

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

---

From: Michael Douglass <[email-masked]>
Date: Fri, 21 Jun 2019 17:27:48 -0400

> (B) For the purpose of comparison specifically declare that:
I'm not sure that's correct. A date value at the moment implies ANY time 
with that date. It depends what you're trying to achieve.

So is 20190315T081500 == 20190315?

Depends.

---

From: Doug Royer <[email-masked]>
Date: Fri, 21 Jun 2019 15:47:50 -0600

> with that date. It depends what you're trying to achieve.

Where is the implication in 5545?

When sorting them on the user interface, are they randomly placed as you 
find them? Or do you place VALUE=DATE items first?

--

---

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

On 6/21/19 17:47, Doug Royer wrote:
>> I'm not sure that's correct. A date value at the moment implies ANY 
>> time with that date. It depends what you're trying to achieve.
>
> When sorting them on the user interface, are they randomly placed as 
> you find them? Or do you place VALUE=DATE items first?

It depends on the UI. But a VALUE=DATE item is often treated differently 
from a date-time, e.g. it reminds me it's somebody's birthday or it's a 
holiday. No alarm set it's just a date.

Sometimes the entire day is colored because there's a date value.

The iPhone (6 and portrait) puts the all-day events in a static bar at 
the top and all the others in a scrollable section - so no they don't 
get sorted first they get separated out in that case

As does the desktop and thunderbird calendar. If I add an event with 
time 00:00 it gets put in the scrollable section at 00:00 as I'd expect.

I think most humans expect an all-day(date only) event to be treated 
differently from an event with a date and time - Most UIs already assume 
that.

In reality I don't think there's much of an issue with date-time and 
date other than what's lacking is a way to signal what people 
colloquially mean by all-day. Google for "all day event" - apart from 
the technical descriptions I get "All day happy hour at UNO". I'm 
guessing they're not serving pizza or anything else happily from 
midnight to midnight.

Or we get "The 2019 Freihofer's Saratoga Jazz Festival" which doesn't go 
from 12:00 AM – 11:59 PM as google claims - it's date only in the ics 
and actually takes place in America/New_York time - but we have no 
(valid) way of saying that. In fact gates open at 10am. If this were a 
streamed event how would I know from my calendar when to watch from e.g 
Hong Kong? But it's an "all day event" because people will be queuing up 
at the gates - strolling around - then listening to performances.

I can guarantee that if we didn't have the distinction between an 
'all-day' date only and 24 hours midnight to midnight we'd have to add 
it as a non-standard property.

To repeat my original request: Can't we simply allow a timezoneid on a 
date?

---

From: Doug Royer <[email-masked]>
Date: Sat, 22 Jun 2019 11:29:01 -0600

> holiday. No alarm set it's just a date.

Yes, when they have no DTEND or DURATION. However they still get sorted 
on the user interface.

> Sometimes the entire day is colored because there's a date value.

iCalendar has no 'all-day' definition. Still waiting to see that that means.

> get sorted first they get separated out in that case

At the top of the day? Is sorted. As there is no such thing as 'all-day' 
in iCalendar, do you mean anniversary (no DTEND or DURATION)? Or 
floating (No time zone)?

> time 00:00 it gets put in the scrollable section at 00:00 as I'd expect.

I assume you mean those that have a DTEND or DURATION? As expected.

> differently from an event with a date and time - Most UIs already assume 

Again: No such thing as 'all-day' in iCalendar. Unless your talking 
about an anniversary that MUST BE a multiple of day (no fractional days 
per 5545).

Types of VEVENTS defined in RFC-5545
"anniversary" is as defined in 3.6.1 and also called a "reminder".

+----------------------------------------------------------------------+
|     | VALUE=  |             |        |                               |
|     | date or | Has DTEND or| Has Z  | Is a...                       |
|     |date-time| or DURATION | or TZID|                               |
+---------------|----------------------|-------------------------------+
| (A) |date-time| Yes         | Yes    |Normal VEVENT starting at      |
|     |         |             |        |specific UTC offset.           | 
          |     |         |             |        |Ending at specific UTC 
Offset  |
+---------------|----------------------|-------------------------------+
| (B) |date-time| Yes         | No     |Normal VEVENT starting at      |
|     |         |             |        |specific local time offset.    |
|     |         |             |        |Ending at specific local Offset|
+---------------|----------------------|-------------------------------+
| (C) |date-time| No          | Yes    | Normal VEVENT.                |
|     |         |             |        | Starts at specific UTC offset.|
|     |         |             |        | Ends at DTSTART.              |
+---------------|----------------------|-------------------------------+
| (D) |date-time| No          | No     | Normal VEVENT.                |
|     |         |             |        | Starts at specific local time |
|     |         |             |        | offset.                       |
|     |         |             |        | Ends at DTSTART.              |
+-----|---------|-------------|--------|-------------------------------+
| (E) | date    | Yes         | Yes    | Anniversary starting at       |
|     |         |             |        | midnight on date              |
|     |         |             |        | as defined by UTC offset.     |
|     |         |             |        | Ends at midnight on days      |
|     |         |             |        | specified by UTC offset.      |
+-----|-----------------------|--------|-------------------------------+
| (F) | date    | Yes         | No     | Anniversary starting at       |
|     |         |             |        | midnight on date              |
|     |         |             |        | as defined by local time      |
|     |         |             |        | offset.                       |
|     |         |             |        | Ends at midnight at specified |
|     |         |             |        | local time offset.            |
+---------------|-------------|--------|-------------------------------+
| (G) | date    | No          | Yes    | Anniversary at midnight       |
|     |         |             |        | at specific UTC offset.       |
|     |         |             |        | Ends at midnight at specified |
|     |         |             |        | UTC offset in DTSTART.        |
+---------------|-------------|--------|-------------------------------+
| (H) | date    | No          | No     | Anniversary at midnight       |
|     |         |             |        | at specific local time offset.|
|     |         |             |        | Ends at midnight at specified |
|     |         |             |        | local time offset in DTSTART. |
+-----|---------|-------------|--------|-------------------------------+

NOTE: A DATE can have a TZID as specified in the ABNF, and the 'date' 
ABNF does NOT allow for a 'Z' on DATE values.

NOTE: A DATE or DATE-TIME values can not have both a TZID
or and a (Z) on the value as quoted here:

In (3.3.5.):

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

and (3.3.12.):

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

and (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. ..."

> guessing they're not serving pizza or anything else happily from 

Then it is NOT 'all-day'. It is a fractional part of a day, and that is 
just makes it a normal VEVENT - nothing special. That would make all-day 
has no more meaning that the color of the display. A meaningless 
attribute that redefines the 'all' in any spoken language.

What 'people' mean by 'all'? Confusing in itself. All the time they are 
open? All Morning? All week? It has no meaning by itself. In effect your
saying "all means all of the time in the normal VEVENT". Which is what a 
normal VEVENT already means.

I (as a people) would expect 'all-day' to mean all 24-hours. I am 
guessing I am not the only one. Some might think it means 
'all-daylight', others might think 'all-work-hours'. No computer program 
can read the context of the VEVENT and guess what hours to consume on 
the user interface - without DTSTART with VALUE=DATE-TIME, and that 
makes it a *normal* VEVENT.

> To repeat my original request: Can't we simply allow a timezoneid on a 

We can. 5545 does not say we can not. (as quoted above), it specifies 
you can not put TWO time zones in the same property. And it says that in 
multiple places. AND the ABNF for  DTSTART, DTEND, EXDATE, and RDATE, 
and DUE allow for DATE-TIME / DATE *and* tzidparam. As they ALL have 
ABNF like this:

  ...param   = *( ...
                   ;
                   ; The following are OPTIONAL,
                   ; but MUST NOT occur more than once.
                   ;
                   (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
                   (";" tzidparam) /
                   ...

--

---

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

Oops, this should be:
|     |         |             |        | Ends DURATION=1 day.          | 

--