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.
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.
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
-------------------------------|-----------------------------
Doug@xxxxxxxxx | Office: (208)612-4638
http://Royer.com | Fax: (866)594-8574
| Cell: (208)520-4044Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature