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

[Cyrus Daboo]

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. So:

Instance 1 (this is the one where DST changes):

DTSTART;TZID=US/Eastern:20050403000000
DTEND;TZID=US/Eastern:20050403080000

Instance 2:

RDATE;TZID=US/Eastern:20050410000000

Note that in instance 1 the clocks go forward an hour at 2 am. So the 
duration of the event is actually 7 hours as opposed to 8 hours. Using your 
algorithm ("Take the rdate and simply add the  difference between dtend and 
dtstart to it") would result in the second instance ending at 7 am. Is that 
what was intended or should it end at 8 am? i.e. is the local end time 
supposed to be fixed or is the duration supposed to be fixed? You would 
have a similar problem if DURATION was used instead of DTEND.

The issue is that right now clients have to infer the end time of 
recurrence instances (after the first one) in some unspecified manner (2445 
does not really explain), unless an RDATE with PERIOD values is used (the 
period explicitly gives both the start and the end).

i.e. to remove any ambiguity the second instance could have been specified 
as:

RDATE;VALUE=PERIOD;TZID=US/Eastern:20050410000000/20050410080000

    (always end at 8 am local time)

or:

RDATE;VALUE=PERIOD;TZID=US/Eastern:20050410000000/20050410070000

    (always run for 7 hours)

depending on what was actually wanted.

-- 
Cyrus Daboo