User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

See enclosed screenshot.

Perhaps side effect of bug 1760805?

libical handles the case without the extra noise.

Still seen in TB 102 beta 7 which includes the fix for bug 1760805.

https://searchfox.org/comm-central/rev/7db3fb60ede28ef82c543940f39e67d7ff0ea7b9/calendar/providers/storage/calStorageHelpers.jsm#189 ->
https://searchfox.org/comm-central/rev/7db3fb60ede28ef82c543940f39e67d7ff0ea7b9/calendar/base/backend/icaljs/calDateTime.js#136 ->
https://searchfox.org/comm-central/rev/7db3fb60ede28ef82c543940f39e67d7ff0ea7b9/calendar/base/modules/Ical.jsm#5519

Looks like libical would do https://searchfox.org/comm-central/rev/7db3fb60ede28ef82c543940f39e67d7ff0ea7b9/calendar/base/backend/libical/calDateTime.cpp#439 which goes to https://searchfox.org/comm-central/rev/7db3fb60ede28ef82c543940f39e67d7ff0ea7b9/calendar/base/backend/libical/calUtils.cpp#39 we should adjust the logic here to do the same

Could you please provide reproduction steps for this issue?

Sorry, no, we just start TB 102 beta on an existing profile. Apparently the calendar data isn't to the liking of IcalJS. There is no error when using libical.

I suspect this lies in events stored in local calendars, but I have been unable to reproduce. Until any sort of reproduction steps can be provided, I'm unable to proceed with work on this.

Due to this error, we weren't using ICaljs (pref calendar.icaljs) for a while until we noticed that the "Today pane" doesn't work any more with libical.

So we finally got around to debugging this. The issue was that zone was passed in as null here:
https://searchfox.org/comm-central/rev/8c1e764a0db62df49c974641013482f4ae5d9c6d/calendar/base/modules/Ical.jsm#5511

Inspecting the database with the SQLite-Browser we found this data in cal_events.event_start_tz and cal_events.event_end_tz:

BEGIN:VTIMEZONE
TZID:(GMT+01.00) Sarajevo/Warsaw/Zagreb
X-MICROSOFT-CDO-TZID:2
BEGIN:STANDARD
DTSTART:16010101T030000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE

So instead of just the TZID Sarajevo/Warsaw/Zagreb, the entire definition of the timezone was stored in the DB field. We don't know how that happened.

The timezone ID (GMT+01.00) Sarajevo/Warsaw/Zagreb isn't one of the standard timezone IDs from the IANA timezone database, so we don't recognize it and have to store the full definition instead. This seems to confirm my suspicions of what's happening here and I believe this is the same as another bug I'm working on.