Subject: [Fwd: Re: Re iCal-Basic - draft 00]

From: Doug Royer <[email-masked]>
Date: Sat, 08 Jan 2005 18:06:08 -0700

I agree that that is an issue for the Organizer (person). Is it an issue
when sharing calendar information?

There is nothing an any draft or RFC that specifies one vs the other is
"fixed" in any way I can find. I *do* see how the Organizer will care
when making the decision.

Once the decision is made that the appointment starts at 2 and lasts 4
hours, (or starts at 2 and ends at 6 in some time zone) there is no way
looking at an iCalendar object to tell why it starts and 2 and lasts 4
hours. DURATION does not imply the length is more fixed in the mind of
the Organizer, and DTEND does not imply the end time is fixed and must
end by DTEND by the Organizer.

So it is a very nice GUI feature for the CU. However I do not see
that it makes a bit of difference to the ATTENDEEs. And I see
no text that supports the assumption that one vs the other implies
the Organizers reasoning.

Some implementations allow the CU to specify DTEND or DURATION, and
always send DTEND and when needed converted from DURATION.

Some implementations allow the CU to specify DTEND or DURATION, and
always send DURATION and when needed converted from DTEND.

Some implementation ask only one of DURATION or DTEND and send only that
one property.

Some implementations always convert DURATION to DTEND and display it as
DTEND to the Attendee.

Some implementations always convert DTEND to DURATION and display it as
DURATION to the Attendee.

It looks to me that it is simply two ways to do he same thing.

(and more embedded below)

Shannon Clark wrote:
> Well while they seem similar they can, in some cases, encode something
> different.
> 
> Specifically - A DTSTART and DTEND without duration can, in the case of
> certain timezones and daylight savings time changes result in difficult
> to determine duration. (i.e. a DTSTART of midnight, a DTEND of 3:00am -
> is that a 3 hour, 2 hour or 4 hour event? Could be any of them depending
> on the date and timezone.

Having both only multiplies the possible assumptions by the number of
unique implementations on the ATTENDEE list resulting in more
incompatibility. DTEND is calculable from DURATION given the TZ info,
else the implementations is bused. (as is DURATION from DTEND).

*AND* as iCal-Basic does not need or have time zones, this point is moot
   until a recurrence rule draft is released?

> 
> Likewise in the same case a DTSTART and DURATION can result is different
> endtimes dependant on certain dates.

Different wall clock times that are 100% calculable each time,
else someone is not doing their math correctly.

> More specifically I think that it was/is an issue of different
> calendaring programs implementing events in each way - some with start
> and end times, other with start and duration (I don't know of any that
> use endtime and duration but technically that could also be used at
> least in theory).

MS stores both DURATION and DTSTART for each expanded instance. I am
not sure if they always convert to one in the unexpanded copy they keep,
or if their unexpanded copy is saved "as is" with respect to DTEND and
DURATION.

Yes I agree. However the math is REALLY easy.

> 
> All three at the same time is broken by many time changes for daylight
> savings.
> 
> It also comes down to what is considered immoveable about the event. Is
> it the DURATION? Or the End time. When the events are either repeating
> or being negotiated the two systems can result in somewhat different
> behaviors and assumptions. There may also be some usecases where it is
> important to switch from one mode to another.
> 
> i.e. "The Meeting HAS TO END BY 5:00pm" - so the DTEND has to be
> considered fixed, if the start time changes, the meeting is shorter -
> not lengthened automatically.
> 
> Alternatively "The test is 4 hours long" - i.e. no matter when the start
> time is rescheduled for, the end time has to be 4 hours later.
> 
> I think the key for the standard is that all of these cases can
> reasonablely be handled, accommodated and dealt with. This may actually
> also require some concept of "fixed vs. negotiable" but that is an issue
> for another day.
> 

The Attendees care when they should show up, when they would expect to
leave (or for how long). Until (IF?) we have a 'why the CUA
implementation decided to use DTEND or DURATION' draft, that is not
determinable from any random iCalendar object received by a CUA.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)612-4638
http://Royer.com               | Fax:    (866)594-8574
                                 | Cell:   (208)520-4044

                We Do Standards - You Need Standards