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

[Reinhold Kainhofer]

Am Sonntag, 3. April 2005 19:13 schrieb Sam Roberts:
> Quoting reinhold at kainhofer.com, on Sun, Apr 03, 2005 at 06:03:05PM +0200:
> > 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 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.
>
> Ok, I thought about this some more, and looked at 4.5.7.2.
>
> So, the issue is that in the 2nd occurence, you have applied the RRULE
> to the DTSTART, so you know the 2nd start. But now you need to find the
> 2nd end. If you do this by calculating an implicit duration from the
> first DTSTART and DTEND, 

Exactly. 

> it will be wrong over DST, leap years, etc. 

I wouldn't say it's wrong. Rather it needs to be clearly worded that the DTEND 
calculation always uses the duration, so the end time is not carved in stone. 

The same problem also appears with Feb 29. 
Here in Austria you get your yearly payment report sometime mid-february, and 
you have to submit the tax sheets at the end of May. Now imagine you create a 
yearly recurring todo for this, which starts on Feb 15, 2004, and has a due 
date of May 31, 2004. In 2005, due to the algorithm described in rfc 2446 
this event will have a due date of June 1, 2005, and you'll submit your tax 
sheet late (and you'll be prosecuted, sentenced to death and executed;-) )


One particular reason why the duration is always used might be recurring 
events that end on 2:30 am. When the time changes from standard time to 
summer time (and vice versa) you'll have either two 2:30am or no 2:30am at 
all. What shall happen to these events? When will they end?


> > 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.
>
> I'm not sure what you mean. You say "this case will never be needed",

Okay, sorry I used a double negation, which in German (my mother tongue) is 
understood as a positive affirmation. I intended to say "I think this is a 
case with some real-world cases, so I don't think we can just ignore it". Or 
put differently, I wanted to negate the previous arguments by Doug on the 
list that all workshift-related events will not need a fixed end time. (But 
then, life doesn't only consists of work...)

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/2fb34ba6/attachment.bin