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

[Doug Royer <[e-mail]>]

On 6/21/19 9:26 PM, Michael Douglass wrote:
> 
> On 6/21/19 17:47, Doug Royer wrote:
>> On 6/21/19 3:27 PM, Michael Douglass wrote:
>>>
>>> On 6/21/19 17:21, Doug Royer wrote:
>>>>
>>>>
>>>> (B) For the purpose of comparison specifically declare that:
>>>>
>>>>     YYYYMMDDT000000
>>>>
>>>>     is the same value as:
>>>>
>>>>     YYYYMMDD
>>>>
>>> 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.
>>
>> 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?
> 
> 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.

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.

> 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

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)?

> 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 assume you mean those that have a DTEND or DURATION? As expected.

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

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


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

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 
> date?

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) /
                   ...


-- 

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