[Ietf-calsify] Re: dtend removed? ( Re: draft-royer-ical-basic-01.txt - sent to IETF)

[Reinhold Kainhofer]

Am Sonntag, 3. April 2005 17:25 schrieb Sam Roberts:
> Hospitals have 3 shifts a day, ending at fixed times, and not
> overlapping.
>
> Offices have 1 shift, starting at 9AM, and we work for 8 hours, no
> matter when the end time is after 8 hours.
>
> RFC2445 allows both to be trivially representable.

Really? I looked at rfc 2445 and tried hard to find out how the end date of 
the recurrences is really calculated. I couldn't find anything definitive in 
the rfc. However, for recurring to-dos, rfc 2446 is quite clear on the 
calculation of the due date of the recurrences. See section 4.5.7.1:
"Calculating due dates in recurring VTODOs"

It is made clear to me that the calculation of the due date always implicitly 
uses the duration, which is either given, or directly calculated from the 
given dtstart and dtend (or due) of the very first occurence. 


BTW, several weeks ago I argued exactly the same ways as you did. I couldn't 
find any hint in rfc 2445 about how to correctly calculate the end date of 
events. And since the only reference was the due-date calculation in rfc 
2446, which doesn't allow your Hospital example (and since Doug also gave 
some sample calculations where he always implicitly used the duration to 
calculate the DTEND), I simply gave up resistence. 

I'd like to have a clear section in rfc 2445 about how the DTEND is calculated 
correctly. And if it is really the case, that all calculations only use the 
duration (explicitly or implicitly if a DTEND is given), we should make it 
very clear that the first example (where the shift always ends at the same 
time, so it might be one hour shorter or longer for the nights when DST 
changes) is simply not possible with iCalendar.

BTW, I don't think that this case will never be needed. E.g. take a schedule 
for the heating of a building. During the night the heating will be turned 
off e.g. from 10 pm to 7am (or the alarm will be set, or the door will be 
locked, or the cleaning crew will work from 10pm to 7am, or whatever).  When 
the DST starts/ends, you definitly don't want the cleaning crew to be still 
working or the alarm still engaged when all workers come to their office at 
7:30am. So these would be examples where the duration is irrelevant, but the 
DTEND is the crucial information. 
But then, I'm not sure if there is really a unique way to calculate the DTEND 
without using the duration...

> Your draft makes one trivial, and the other has to be represented as 3
> objects.

It's already the same in rfc 2445. Either I'm missing something, or rfc 2445 
is simply lacking this capability (as strange as it may seem considering how 
over-engineered it is).

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: reinhold at kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050403/73c9144f/attachment.bin