[Ietf-calsify] Re: dtend removed? ( Re: draft-royer-ical-basic-01.txt - sent to IETF)
reinhold at kainhofer.com
Sun Apr 3 09:03:05 PDT 2005
Am Sonntag, 3. April 2005 17:25 schrieb Sam Roberts:
> Hospitals have 3 shifts a day, ending at fixed times, and not
> 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 22.214.171.124:
"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
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).
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
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050403/73c9144f/attachment.bin
More information about the Ietf-calsify