node-ical icon indicating copy to clipboard operation
node-ical copied to clipboard

Wrong datetime for recurring events

Open runely opened this issue 3 years ago • 5 comments

There seems to be a bug when a recurring event has it's initial start datetime one recurrence before DST timezone change. The one recurrence event before the change will be correct, all next events after seems to be using the first events timezone even though it should have changed, making them all wrong.

Here’s an example of a ics which has this problem

When parsed through node-ical the first event has correct time but the day is wrong (probably because it passes 00:00 AM). All next events should have changed timezone but are still using the same timezone as the initial datetime

ICS
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-TIMEZONE:Australia/Adelaide
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VTIMEZONE
TZID:Australia/Adelaide
X-LIC-LOCATION:Australia/Adelaide
BEGIN:STANDARD
TZOFFSETFROM:+1030
TZOFFSETTO:+0930
TZNAME:ACST
DTSTART:19700405T030000
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0930
TZOFFSETTO:+1030
TZNAME:ACDT
DTSTART:19701004T020000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=1SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Australia/Adelaide:20210401T093000
DTEND;TZID=Australia/Adelaide:20210401T120000
RRULE:FREQ=WEEKLY;WKST=MO;UNTIL=20220506T142959Z;BYDAY=TH
DTSTAMP:20210402T040825Z
UID:[email protected]
CREATED:20210218T020324Z
DESCRIPTION:
LAST-MODIFIED:20210331T222932Z
LOCATION:
SEQUENCE:2
STATUS:CONFIRMED
SUMMARY:clear space
TRANSP:TRANSPARENT
END:VEVENT
END:VCALENDAR

Here’s an example of a ics which does not have this problem

This ics does not have this problem because the inital start datetime is just passed the timezone change. When parsed through node-ical, all events has correct datetime

ICS
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-TIMEZONE:Australia/Adelaide
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VTIMEZONE
TZID:Australia/Adelaide
X-LIC-LOCATION:Australia/Adelaide
BEGIN:STANDARD
TZOFFSETFROM:+1030
TZOFFSETTO:+0930
TZNAME:ACST
DTSTART:19700405T030000
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0930
TZOFFSETTO:+1030
TZNAME:ACDT
DTSTART:19701004T020000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=1SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Australia/Adelaide:20210408T093000
DTEND;TZID=Australia/Adelaide:20210408T120000
RRULE:FREQ=WEEKLY;WKST=MO;UNTIL=20220506T142959Z;BYDAY=TH
DTSTAMP:20210402T040825Z
UID:[email protected]
CREATED:20210218T020324Z
DESCRIPTION:
LAST-MODIFIED:20210331T222932Z
LOCATION:
SEQUENCE:2
STATUS:CONFIRMED
SUMMARY:clear space
TRANSP:TRANSPARENT
END:VEVENT
END:VCALENDAR

runely avatar Apr 05 '21 10:04 runely

Hi runely,

Seems any set of recurrences that cross a DST change results in this issue (not just one recurrence before)?

I have an open issue dealing with DST issues - #97 . Not perfect (as described) but works for me.

Hope that is useful.

scmunro avatar Apr 07 '21 03:04 scmunro

In my testing this only occured when there’s only one recurrence before. If there’s two recurrences or more it works as it should.

runely avatar Apr 08 '21 17:04 runely

Any thoughts on this?

runely avatar May 08 '21 21:05 runely

this is still an issue

yoont4 avatar Jun 05 '21 02:06 yoont4

RRULE expects non TZ based dates/times.. and doesn't understand DST

sdetweil avatar Nov 15 '23 16:11 sdetweil