[Ietf-calsify] 2nd and higher instance busted across time zone changes.

[Reinhold Kainhofer]

Am Sonntag, 10. April 2005 03:59 schrieben Sie:
> Hi Reinhold,
>
> --On Sunday, April 10, 2005 02:15:52 AM +0200 Reinhold Kainhofer
>
> <reinhold at kainhofer.com> wrote:
> > 45 minutes after the 1st instance ended. (Take the rdate and simply add
> > the  difference between dtend and dtstart to it).
>
> No - you are missing the point. Lets explain this again a little
> differently:
>
> Consider an event that occurs twice between the hours of 12 am and 8 am
> local time (EST is used in my example). It occurs on two consecutive
> Sundays. One of those Sundays involves a daylight savings change. 

Ah, sorry. I didn't know that US/Eastern time switches to DST in April. 
Everywhere here in Europe the DST changes occur on the last sunday in march 
and the last sunday in October.

Basically, your problem just makes it clear what I meant by "But then, I'm not 
sure if there is really a unique way to calculate the DTEND 
without using the duration..." in my mail on April 3 
(http://lists.osafoundation.org/pipermail/ietf-calsify/2005-April/000483.html).

Actually, as long as the frequency is >= daily in an RRULE (without a BYHOUR 
or BYMINUTE value), or no new time is given in an RDATE, the end time can be 
taken from the original DTEND. But as soon as the start time changes compared 
to the first occurence, you're out of luck.

The same problem happens with the date and leap years. And there it happens 
even without strange things like an RDATE with explicit time. Just take 
weekly recurrence rules. How will you ever correctly calculate the end date, 
since you only have the n-th day of the month available from the DTEND. But 
since you are using weekly recurrence, the only information that you have 
available is the duration.

E.g. take the event 
DTSTART;VALUE=DATE:20040206
DTEND;VALUE=DATE:20040211
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=FR

The occurences will be 
-) Feb 6 - 10, 2004
-) Feb 13 - 17, 2004
-) Feb 20 - 24, 2004

And the next one creates the problems: It will be Feb 27 - March 2, 2004, 
right (where you use the duration to calculate the end date)? The only 
information that you can use here is the duration.

So, only in some cases is it possible to use the real end date to obtain more 
information. In some cases only the duration is available. the question now 
is whether the standard should just use duration-based end date / times , or 
whether it should be smart and describe when it's possible to use more 
information about the end date/time and when one needs to use the duration. 
My guess is that the latter is quite tricky to get right and water-proof.




Now take a monthly event:
RRULE:FREQ=MONTHLY;INTERVAL=1;BYMONTHDAY=27
DTSTART;VALUE=DATE:20040127
DTEND;VALUE=DATE:20040203

If you want to take the end date from the DTEND (which is basically what is 
suggested on calsify), you'll have the following events:

-) Jan 27 - Feb 2, 2004 (7 days)
-) Feb 27 - March 2, 2004 (5 days)
-) March 27 - April 2, 2004 (7 days)
-) April 27 - May 2, 2004 (6 days)

Okay, so this event has a varying duration. Now imagine an additional
RDATE;VALUE=DATE:20040225

When will this occurence end? The only information that you have now available 
is the duration.

So, this problem is not restricted to RDATEs that give a different start time 
than the first occurence, but it also happens with date-only events.

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/20050410/aac69b58/attachment.bin