Read the statement by Michael Teeuw here.
Issue with Outlook recurring events
-
I’m back with more calendar woes.
I’m apparently still having an issue where events in my Outlook calendar can under certain circumstances not appear on my MM. This is again a symptom of the event’s rrule ending prior to the last event in the series. Some ICS code below:
BEGIN:VCALENDAR METHOD:PUBLISH PRODID:Microsoft Exchange Server 2010 VERSION:2.0 X-WR-CALNAME:My Calendar BEGIN:VTIMEZONE TZID:GMT Standard Time BEGIN:STANDARD DTSTART:16010101T020000 TZOFFSETFROM:+0100 TZOFFSETTO:+0000 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10 END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T010000 TZOFFSETFROM:+0000 TZOFFSETTO:+0100 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT RRULE:FREQ=WEEKLY;UNTIL=20251007T164500Z;INTERVAL=1;BYDAY=TU;WKST=MO EXDATE;TZID=GMT Standard Time:20250930T174500 UID:040000008200E00074C5B7101A82E008000000004ECDB12BC10FDC01000000000000000 010000000012DADF723AF8140B35A2E374506E8D9 SUMMARY:My Event DTSTART;TZID=GMT Standard Time:20250826T174500 DTEND;TZID=GMT Standard Time:20250826T183000 CLASS:PUBLIC PRIORITY:5 DTSTAMP:20251006T181942Z TRANSP:OPAQUE STATUS:CONFIRMED SEQUENCE:0 LOCATION: X-MICROSOFT-CDO-APPT-SEQUENCE:0 X-MICROSOFT-CDO-BUSYSTATUS:BUSY X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INSTTYPE:1 X-MICROSOFT-DONOTFORWARDMEETING:FALSE X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MICROSOFT-REQUESTEDATTENDANCEMODE:DEFAULT X-MICROSOFT-ISRESPONSEREQUESTED:FALSE END:VEVENT END:VCALENDAR
I’m not sure if this is something that can be resolved, or why it happens but I suspect some timezone issue as I’m based in the UK and we have to endure changing the clocks twice a year.
Having said that, the ICS file does not reflect the settings in the calendar for that event:
Anyone got any suggestions? Sorry to be a pest with this one!
-
@WallysWellies the event looks correct according to the start/end and rrule
ButWe do not use the custom timezone configuration in the iCal data
We use the worldwide standard IANA tz names
(Why one needs custom timezones is beyond me)Because so many users use MS products , I wrote a lookup table 5 years ago for the calendar parser we use, node-iCal
But
GMT Standard Time
Is not in that table (GMT has long been replaced by UTC)
UTC Standard Time
Is in the table
If the tz lookup fails, we use the local system timezone
-
The calendar automatically adjusts for STD/DST time changes
-
I don’t know why the rrule until says oct 08:164500, but oct 7 is the last Tuesday in the event cycle
Sept 30 was excluded
So all the iCal entry looks good except for the timezone
-
@sdetweil the timezone on my Pi is:
Local time: Mon 2025-10-06 20:26:51 BST Universal time: Mon 2025-10-06 19:26:51 UTC RTC time: Mon 2025-10-06 19:26:51 Time zone: Europe/London (BST, +0100) System clock synchronized: yes NTP service: active RTC in local TZ: no
Is there something I need to do to try and resolve this? My MS calendar is set to a UTC timezone:
-
@WallysWellies but iCal is reporting gmt
-
@sdetweil because Microsoft? Not really sure.
I’ve been digging into the iCal stuff and I see the windowsZones.json file which I presume does your MS to IANA mapping. In there is this line:
"GMT Standard Time":{"iana":["Europe/London"]}
Is that what you were referring to - should this not replace the GMT timezone with the IANA equivalent? I’m just wading through code I only partially understand…!
I can ask a few people for sample icals to see if my GTM timezone is an oddity if that’s any use.
-
@WallysWellies can you add
stop MM
, "DEBUG"
to the logLevel value in config.js at the top
and then start MM in debug modecd ~/MagicMirror npm start >somefile.txt 2>&1
wait til the calendar is up
then
ctrl-q on the MM screen to shut it downthen examine somefile.txt
(careful if posting, the debug log contains the full URL of the calendar from config.js) -
I think this is the relevant entry from the log:
[2025-10-07 07:52:10.434] [DEBUG] parsed data={ "040000008200E00074C5B7101A82E008000000004ECDB12BC10FDC01000000000000000010000000012DADF723AF8140B35A2E374506E8D9": { "type": "VEVENT", "params": [], "rrule": { "_cache": { "all": false, "before": [], "after": [], "between": [] }, "origOptions": { "tzid": "Europe/London", "dtstart": "2025-08-26T17:45:00.000Z", "freq": 2, "until": "2025-10-07T16:45:00.000Z", "interval": 1, "byweekday": [ { "weekday": 1 } ], "wkst": { "weekday": 0 } }, "options": { "freq": 2, "dtstart": "2025-08-26T17:45:00.000Z", "interval": 1, "wkst": 0, "count": null, "until": "2025-10-07T16:45:00.000Z", "tzid": "Europe/London", "bysetpos": null, "bymonth": null, "bymonthday": [], "bynmonthday": [], "byyearday": null, "byweekno": null, "byweekday": [ 1 ], "bynweekday": null, "byhour": [ 17 ], "byminute": [ 45 ], "bysecond": [ 0 ], "byeaster": null } }, "exdate": [], "uid": "040000008200E00074C5B7101A82E008000000004ECDB12BC10FDC01000000000000000010000000012DADF723AF8140B35A2E374506E8D9", "summary": "My Event", "start": "2025-08-26T16:45:00.000Z", "datetype": "date-time", "end": "2025-08-26T17:30:00.000Z", "class": "PUBLIC", "priority": "5", "dtstamp": "2025-10-07T06:52:10.000Z", "transparency": "OPAQUE", "status": "CONFIRMED", "sequence": "0", "location": "", "MICROSOFT-CDO-APPT-SEQUENCE": "0", "MICROSOFT-CDO-BUSYSTATUS": "BUSY", "MICROSOFT-CDO-INTENDEDSTATUS": "BUSY", "MICROSOFT-CDO-ALLDAYEVENT": "FALSE", "MICROSOFT-CDO-IMPORTANCE": "1", "MICROSOFT-CDO-INSTTYPE": "1", "MICROSOFT-DONOTFORWARDMEETING": "FALSE", "MICROSOFT-DISALLOW-COUNTER": "FALSE", "MICROSOFT-REQUESTEDATTENDANCEMODE": "DEFAULT", "MICROSOFT-ISRESPONSEREQUESTED": "FALSE", "method": "PUBLISH" } }]
The timezone does look to be getting updated to the IANA string. But line 33 has:
"until": "2025-10-07T16:45:00.000Z",
but the final event should be starting at 17:45 and ending at 18:30. So the ical does seem to imply that the series ends prior to the final event starting. Even if we account for the hour difference due to a potential timezone issue, the series is ending right as the final event starts.
Is there a particular part of the log that might be useful for digging deeper - a search string I can use to narrow things down? Or are we just looking at another Microsoft quirk…
-
@WallysWellies the ICS has
RRULE:FREQ=WEEKLY;UNTIL=20251007T164500Z;INTERVAL=1;BYDAY=TU;WKST=MOso its a source problem. the parser processed this correctly.
we have no idea why its set like this, we just process the ICS data.but the until is weird
Until Oct 08 (in the UI) , which isn’t a Tuesday, so the event could not happen then anyhow.
I’d try changing that and see what happens with the ICS data