@sdetweil @inteeraymee
I have the same issue after updating from MagicMirror 2.34.0 to 2.35.0.
In my case this is not a general calendar config problem and not an auth/fetch problem either. Some calendars still load fine, others fail right after the update, which pointed me to a parser regression.
What I found:
MagicMirror 2.34.0 used node-ical 0.22.1
MagicMirror 2.35.0 uses node-ical 0.25.6
The affected calendars are fetched successfully with HTTP 200
The failure happens during ICS parsing
These are the two of the log lines I get:
[ERROR] [calendar] https://<server>/remote.php/dav/calendars/xx1/?export - iCal parsing failed: Cannot parse: 1-01-15T12:00:00Z
[DEBUG] [calendar] Parsed iCal data from https://<server>/remote.php/dav/calendars/xx2/?export with 130 entries.
The important detail in the broken ICS files is this VTIMEZONE block:
BEGIN:VTIMEZONE
TZID:W. Europe Standard Time
BEGIN:DAYLIGHT
DTSTART:00010325T020000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:00011028T030000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
I tested the exact same ICS file with both node-ical versions:
node-ical 0.22.1: parses successfully
node-ical 0.25.6: fails with Cannot parse: 1-01-15T12:00:00Z
I also verified that if I remove only that W. Europe Standard Time VTIMEZONE block from the failing ICS, the file parses again with node-ical 0.25.6.
So the problem seems to be a regression in node-ical 0.25.x when resolving VTIMEZONE definitions with year 0001 in DTSTART. The calendar fetch itself succeeds; the crash happens while parsing timezone metadata.
This may especially affect calendars coming from Outlook/Exchange/Nextcloud imports, because W. Europe Standard Time looks like a Microsoft-style timezone definition.