[caldeveloper-l] Timezone recurrence rule query

[Michael Douglass]

This raises a whole bunch of issues...

First - there is no difference in evaluation of rules - whatever the 
context.

Some clients and servers send a compressed timezone definition which is 
only valid for the date/time range of the associated event.

Most clients and servers ignore the timezone definition anyway. We 
carried out a number of tests some time back and as long as it's a 
recognized id it's usually ignored.

We did this as a run-up to this spec - 
https://tools.ietf.org/html/rfc7809 which allows caldav servers to 
optionally skip the tz definition.

Not only is it usually ignored but it's often bigger than the actual event.

So I guess one question is - does that tz def actually work for the 
event date in question? And does that match what you'd get if you used 
an up to date full spec?

This issue - among other things was behind tzdist - 
https://tools.ietf.org/html/rfc7808

Just for ref below is an (oldish) version of the spec for that zone

BEGIN:VCALENDAR
PRODID:-//tzurl.org//NONSGML Olson 2018g-rearguard//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/London
TZURL:http://tzurl.org/zoneinfo/Europe/London
X-LIC-LOCATION:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19810329T010000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
TZNAME:GMT
DTSTART:19961027T020000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:STANDARD
TZOFFSETFROM:-000115
TZOFFSETTO:+0000
TZNAME:GMT
DTSTART:18471201T000000
RDATE:18471201T000000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19160521T020000
RDATE:19160521T020000
RDATE:19170408T020000
RDATE:19180324T020000
RDATE:19190330T020000
RDATE:19200328T020000
RDATE:19210403T020000
RDATE:19220326T020000
RDATE:19230422T020000
RDATE:19240413T020000
RDATE:19250419T020000
RDATE:19260418T020000
RDATE:19270410T020000
RDATE:19280422T020000
RDATE:19290421T020000
RDATE:19300413T020000
RDATE:19310419T020000
RDATE:19320417T020000
RDATE:19330409T020000
RDATE:19340422T020000
RDATE:19350414T020000
RDATE:19360419T020000
RDATE:19370418T020000
RDATE:19380410T020000
RDATE:19390416T020000
RDATE:19400225T020000
RDATE:19460414T020000
RDATE:19470316T020000
RDATE:19480314T020000
RDATE:19490403T020000
RDATE:19500416T020000
RDATE:19510415T020000
RDATE:19520420T020000
RDATE:19530419T020000
RDATE:19540411T020000
RDATE:19550417T020000
RDATE:19560422T020000
RDATE:19570414T020000
RDATE:19580420T020000
RDATE:19590419T020000
RDATE:19600410T020000
RDATE:19610326T020000
RDATE:19620325T020000
RDATE:19630331T020000
RDATE:19640322T020000
RDATE:19650321T020000
RDATE:19660320T020000
RDATE:19670319T020000
RDATE:19680218T020000
RDATE:19720319T020000
RDATE:19730318T020000
RDATE:19740317T020000
RDATE:19750316T020000
RDATE:19760321T020000
RDATE:19770320T020000
RDATE:19780319T020000
RDATE:19790318T020000
RDATE:19800316T020000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
TZNAME:GMT
DTSTART:19161001T030000
RDATE:19161001T030000
RDATE:19170917T030000
RDATE:19180930T030000
RDATE:19190929T030000
RDATE:19201025T030000
RDATE:19211003T030000
RDATE:19221008T030000
RDATE:19230916T030000
RDATE:19240921T030000
RDATE:19251004T030000
RDATE:19261003T030000
RDATE:19271002T030000
RDATE:19281007T030000
RDATE:19291006T030000
RDATE:19301005T030000
RDATE:19311004T030000
RDATE:19321002T030000
RDATE:19331008T030000
RDATE:19341007T030000
RDATE:19351006T030000
RDATE:19361004T030000
RDATE:19371003T030000
RDATE:19381002T030000
RDATE:19391119T030000
RDATE:19451007T030000
RDATE:19461006T030000
RDATE:19471102T030000
RDATE:19481031T030000
RDATE:19491030T030000
RDATE:19501022T030000
RDATE:19511021T030000
RDATE:19521026T030000
RDATE:19531004T030000
RDATE:19541003T030000
RDATE:19551002T030000
RDATE:19561007T030000
RDATE:19571006T030000
RDATE:19581005T030000
RDATE:19591004T030000
RDATE:19601002T030000
RDATE:19611029T030000
RDATE:19621028T030000
RDATE:19631027T030000
RDATE:19641025T030000
RDATE:19651024T030000
RDATE:19661023T030000
RDATE:19671029T030000
RDATE:19711031T030000
RDATE:19721029T030000
RDATE:19731028T030000
RDATE:19741027T030000
RDATE:19751026T030000
RDATE:19761024T030000
RDATE:19771023T030000
RDATE:19781029T030000
RDATE:19791028T030000
RDATE:19801026T030000
RDATE:19811025T020000
RDATE:19821024T020000
RDATE:19831023T020000
RDATE:19841028T020000
RDATE:19851027T020000
RDATE:19861026T020000
RDATE:19871025T020000
RDATE:19881023T020000
RDATE:19891029T020000
RDATE:19901028T020000
RDATE:19911027T020000
RDATE:19921025T020000
RDATE:19931024T020000
RDATE:19941023T020000
RDATE:19951022T020000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:BDST
DTSTART:19410504T020000
RDATE:19410504T020000
RDATE:19420405T020000
RDATE:19430404T020000
RDATE:19440402T020000
RDATE:19450402T020000
RDATE:19470413T020000
END:DAYLIGHT
BEGIN:DAYLIGHT
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19410810T030000
RDATE:19410810T030000
RDATE:19420809T030000
RDATE:19430815T030000
RDATE:19440917T030000
RDATE:19450715T030000
RDATE:19470810T030000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:19681027T000000
RDATE:19681027T000000
END:STANDARD
BEGIN:STANDARD
TZOFFSETFROM:+0000
TZOFFSETTO:+0000
TZNAME:GMT
DTSTART:19960101T000000
RDATE:19960101T000000
END:STANDARD
END:VTIMEZONE
END:VCALENDAR


On 2/10/20 06:58, Paul Smith wrote:
> I have a event with the following ICS source. My implementation of 
> recurrence rules is interpreting the timezone as changing to BST on 
> the first Sunday of March. It should be the last Sunday.
>
> Most CalDAV clients seem to set the Timezone RRULE to
>
> RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
>
> which is processed correctly, but this one just uses ...BYDAY=SU which 
> is being processed as 'every Sunday in March' (as described in RFC 
> 5545, section 3.3.10 ("If an integer modifier is not present, it means 
> all days of this type within the specified frequency. For example, 
> within a MONTHLY rule, MO represents all Mondays within the month")
>
> So, the recurrence event on 3rd March 2020 is at 11:50 UTC, instead at 
> 12:50 UTC.
>
> Other CalDAV viewers I've tried (Mac Calendar, Mozilla Lightning) seem 
> to be handling it correctly, but I'm not sure if they're processing 
> the Timezone recurrence in a different way to my implementation, or if 
> they're just saying 'Hey, that's BST, I know what BST is, so I'll 
> ignore the Timezone definition in the event and do it my own way'.
>
> So, my question is: - should 'BYDAY=SU' be interpreted differently in 
> a Timezone definition than in other places (if so, where is that 
> described), or is the client which is generating this event getting it 
> wrong?
>
> --------------
>
> BEGIN:VCALENDAR
> VERSION:2.0
> PRODID:-//LigatureTech LLC.//SimpleCal 1.0.0//EN\r+
> CALSCALE:GREGORIAN
> BEGIN:VTIMEZONE
> TZID:Europe/London
> BEGIN:DAYLIGHT
> TZNAME:BST
> TZOFFSETFROM:0000
> TZOFFSETTO:0100
> RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=SU
> DTSTART:19700329T010000
> END:DAYLIGHT
> BEGIN:STANDARD
> TZNAME:GMT
> TZOFFSETFROM:0100
> TZOFFSETTO:0000
> RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=SU
> DTSTART:19701025T020000
> END:STANDARD
> END:VTIMEZONE
> BEGIN:VEVENT
> UID:c8687991-80fa-4c2a-b273-3fb2f72a4c7c
> SUMMARY:test
> DTSTART;TZID=Europe/London:20200129T125000
> DTEND;TZID=Europe/London:20200129T135000
> RRULE:FREQ=DAILY
> DTSTAMP:20200129T142840Z
> CREATED:20200129T111403Z
> LAST-MODIFIED:20200129T142840Z
> SEQUENCE:1
> TRANSP:OPAQUE
> DESCRIPTION:test event 12
> END:VEVENT
> END:VCALENDAR
>
> --------------
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.calconnect.org/pipermail/caldeveloper-l-calconnect.org/attachments/20200210/8f4af7a0/attachment.html>