[Ietf-calsify] 2nd and higher instance busted across time zone changes.
reinhold at kainhofer.com
Sun Apr 10 10:16:11 PDT 2005
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
> 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
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
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:
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
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.
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/20050410/aac69b58/attachment.bin
More information about the Ietf-calsify