[Ietf-calsify] Re: dtend removed? ( Re: draft-royer-ical-basic-01.txt - sent to IETF)
reinhold at kainhofer.com
Sun Apr 3 11:00:01 PDT 2005
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 18.104.22.168.
> 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,
> 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 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/2fb34ba6/attachment.bin
More information about the Ietf-calsify