Timezones are not processed correctly at import of ICS file

[openfnord]

Checklist

• I can reproduce the bug with the latest version given here.
• I made sure that there are no existing issues - open or closed - to which I could contribute my information.
• I made sure that there are no existing discussions - open or closed - to which I could contribute my information.
• I have read the FAQs inside the app (Menu -> About -> FAQs) and my problem isn't listed.
• I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
• This issue contains only one bug.
• I have read and understood the contribution guidelines.

Affected app version

1.2.0

Affected Android/Custom ROM version

Android 15 (Xiaomi 2.0.4.0.VNTEUXM)

Affected device model

Redmi13

How did you install the app?

F-Droid / IzzyOnDroid

Which calendar service or provider do you use, if any?

No response

Which sync adapter app do you use for calendar synchronization, if any?

No response

Steps to reproduce the bug

I missed a ms teams conference with my professor regarding my PhD because Calender does not honor time zones correctly.
To reproduce open the file msteamsinvite.ics (remove txt for acceptance) with calendar. Note the start time of the meeting is 11h and not 10h as it should be if you have central european summer time. Note the meeting invite uses israeli standard time ;-)
Neglect to detail on both sides caused the meeting to fail.

A user would expect calendar at least to produce a pop-up warning about different time zone in the ICS file and the time zone set for the android device.

The critical part in the ICS is here:
"
BEGIN:VTIMEZONE
TZID:Israel Standard Time
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1FR;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
"
We have daylight saving in europe and israel and also we have israeli time zone vs european time zone.

This should be fixed to prevent people missing their important meetings.
Best would be to implement proper parsing of ICS VTIMEZONE and time zone handling using a proper library for time zones.

msteamsinvite.ics.txt

Expected behavior

The user imports the ICS file and the timezone is properly parsed and the date is correctly calculated including time and timezone so the meeting is scheduled at the right time regardless which time zone the sender and producer oi ICS uses and the time zone the user of calendar uses.

msteamsinvite.ics.txt

Actual behavior

The user imports the ICS file and the timezone is NOT properly parsed and the date is NOT correctly calculated including time and timezone so the meeting is scheduled at the WRONG time when the time zone of the sender and producer oi ICS is DIFFERENT from the time zone the user of calendar uses.

This leads to missed meetings!

msteamsinvite.ics.txt

Screenshots/Screen recordings

No response

Additional information

No response

[savar]

another one.. timezone on the phone and in the ICS are the same, still it should have been starting 2025-04-22T12:30:00+0200 but it was 2025-04-22T14:30+0200 as if the 2 hours UTC offset was simply added.

BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 11.0 MIMEDIR//EN
VERSION:2.0
METHOD:PUBLISH
X-WR-TIMEZONE:Europe/Berlin
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
DTSTART:19700329T020000
RRULE:BYMONTH=3;FREQ=YEARLY;BYDAY=-1SU
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19701025T030000
RRULE:BYMONTH=10;FREQ=YEARLY;BYDAY=-1SU
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER:MAILTO:Salon.alt-tegel@lars-cordes-hairdesign.de
DTSTART:20250422T123000
DTEND:20250422T131500
TRANSP:OPAQUE
SEQUENCE:0
UID:1744731173-1195@e-cut.de
DTSTAMP:20250415T173253
DESCRIPTION:Gewünschte Dienstleistungen:\n- HERRENHAARSCHNITT\n\nMita
 rbeiter: Susanne (Profi)\n\nDas Someone Somewhere hairdesign Salon 
 -Team freut sich auf Ihren Besuch!\n\n
SUMMARY:Someone Somewhere hairdesign Salon 
PRIORITY:5
CLASS:PUBLIC
END:VEVENT
END:VCALENDAR

[kuflierl]

Same issue here on 1.2.0 FDroid on graphene os.

My train connection was shown as 2 hours later due to bad timezone interpretation. The time is interpreted as UTC as given but not corrected for the timezone.

[englut]

I'm also experiencing this issue. Would be good to address timezones.

[watermelonwolverine]

I experienced a similar bug on version 1.6.2.
I almost missed an important job interview because of this. Luckily one of the interviewers sent me an email asking me were I was.
This bug can cause some real damage.

[kirkawolff]

My AI slopped this out. Take it for what it is.

Root cause

Outlook / Exchange emits Windows time zone IDs (e.g. TZID:W. Europe Standard Time) instead of IANA/Olson IDs (Europe/Berlin, etc.).
Fossify appears to not reliably resolve these TZIDs or apply the embedded VTIMEZONE, so events are imported using the wrong offset (typically ±1 hour around DST), especially when the producer TZ ≠ device TZ.

This is a producer reality, not a malformed ICS: RFC 5545 allows arbitrary TZID tokens, and Outlook always uses Windows TZIDs.

Proposed fix (importer-side)

1. Detect Windows TZIDs

   • If TZID does not contain / and matches known Windows IDs, treat it as a Windows TZID.

2. Map Windows → IANA

   • Map the Windows TZID to an IANA zone using the Unicode CLDR mapping (windowsZones.xml).
   • If territory is unknown, use the 001 mapping or device region as a heuristic.

3. Always honor embedded VTIMEZONE

   • If a VTIMEZONE component exists for the event’s TZID, apply it per RFC 5545.
   • Only fall back to device local time if:
     • the TZID cannot be resolved and
     • no usable VTIMEZONE definition is present.

4. (Secondary) Be tolerant of Outlook transport artifacts

   • Outlook ICS often includes quoted-printable line breaks, folded lines, and UTF-8 display names.
   • Normalizing these before parsing avoids downstream failures, though this is not the primary time-shift bug.

Why this matters

Outlook/Exchange is the dominant enterprise ICS producer and is historically not going to change its TZID behavior.
Importer-side Windows→IANA mapping is how other ecosystems handle this (Java, ICU, CLDR consumers) and is the only realistic path to correct interop.

Suggested tests

• Import an Outlook ICS with:
  • Windows TZID + embedded VTIMEZONE
  • Device in a different TZ
  • Dates spanning DST boundaries
• Assert the resulting UTC instant matches the original meeting time.

[iosonofabio]

Also having time zone issues, a couple meetings are rigjt time but wrong day (here in Australia meetings are often on the next day compared to EU and US).

[Hazematman]

Another data point. This event has a time of 13:30-14:30 UTC but in fossify calendar shows as 9:30-10:30EST in the calendar (my time zone is EST), which if converted properly should be 8:30-9:30 EST.

BEGIN:VCALENDAR
PRODID:-//Fossify//NONSGML Event Calendar//EN
VERSION:2.0
BEGIN:VEVENT
SUMMARY:<REDACTED>
UID:Caldav-9-988
X-FOSSIFY-CATEGORY-COLOR:-5592406
CATEGORIES:Personal Calendar
LAST-MODIFIED:19700101T000000Z
TRANSP:OPAQUE
LOCATION:<REDACTED>
DTSTART:20250401T133000Z
DTEND:20250401T143000Z
X-FOSSIFY-MISSING-YEAR:0
DTSTAMP:20260303T141523Z
CLASS:PUBLIC
STATUS:CONFIRMED
RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=TU
DESCRIPTION:<REDACTED>
BEGIN:VALARM
DESCRIPTION:Reminder
ACTION:DISPLAY
TRIGGER:-P0DT0H15M0S
END:VALARM
BEGIN:VALARM
DESCRIPTION:Reminder
ACTION:DISPLAY
TRIGGER:-P0DT0H30M0S
END:VALARM
BEGIN:VALARM
DESCRIPTION:Reminder
ACTION:DISPLAY
TRIGGER:-P0DT0H30M0S
END:VALARM
END:VEVENT
END:VCALENDAR