Skip to content

Timezones are not processed correctly at import of ICS file #535

Open
Open
Timezones are not processed correctly at import of ICS file#535
Labels
bugSomething is not working

Description

@openfnord
openfnord
opened on Apr 18, 2025

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

Activity

  1. openfnord
    added
    bugSomething is not working
    needs triageIssue is not yet ready for PR authors to take up
    on Apr 18, 2025
  2. naveensingh
    removed
    needs triageIssue is not yet ready for PR authors to take up
    on Apr 18, 2025

  3. savar commented on Apr 23, 2025

    @savar
    savar
    on Apr 23, 2025

    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

  4. kuflierl commented on Apr 23, 2025

    @kuflierl
    kuflierl
    on Apr 23, 2025

    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.

  5. englut commented on Aug 20, 2025

    @englut
    englut
    on Aug 20, 2025

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

  6. watermelonwolverine commented on Oct 22, 2025

    @watermelonwolverine
    watermelonwolverine
    on Oct 22, 2025

    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.

  7. kirkawolff commented on Jan 9, 2026

    @kirkawolff
    kirkawolff
    on Jan 9, 2026

    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.
  8. naveensingh
    added
    confirmed
    accepted
    and removed
    confirmed
    on Jan 27, 2026

  9. iosonofabio commented on Feb 8, 2026

    @iosonofabio
    iosonofabio
    on Feb 8, 2026

    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).

  10. Hazematman commented on Mar 3, 2026

    @Hazematman
    Hazematman
    on Mar 3, 2026

    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
  11. naveensingh
    removed
    accepted
    on Jul 14, 2026

  12. BrunswickBTC commented on Sep 4, 2026

    @BrunswickBTC
    BrunswickBTC
    on Sep 4, 2026

    Additional reproducible case: Microsoft Outlook/Teams invite

    I found a current production example of the timezone-import bug described here. The invite was generated by Microsoft Exchange/Teams and imported into Fossify Calendar on a GrapheneOS Android phone whose device timezone is America/Chicago (CDT).

    ICS input

    The invitation contains an embedded VTIMEZONE with the Microsoft/Windows identifier:

    BEGIN:VTIMEZONE
TZID=Eastern Standard Time
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE

    The event itself is:

    DTSTART;TZID=Eastern Standard Time:20260908T140000
DTEND;TZID=Eastern Standard Time:20260908T143000

    Actual behavior

    Fossify imported and displayed the event as 2:00 PM CDT.

    Expected behavior

    September 8 is daylight time in this zone, so the event is 2:00 PM EDT, which should display as 1:00 PM CDT on a device in America/Chicago.

    Root cause indication

    The current importer appears to ignore the embedded VTIMEZONE. IcsImporter.getTimestamp() only changes from the device default when the TZID exactly matches a Joda/IANA timezone ID. Eastern Standard Time is a Microsoft/Windows timezone ID, so it is not recognized and the importer falls back to the device timezone while interpreting the literal 14:00.

    This is a concrete interoperability case with Outlook/Exchange, not a malformed ICS. The fix should either honor the embedded VTIMEZONE or map Windows timezone IDs to IANA zones (for example through CLDR/Windows zone mappings), with tests covering DST and a device in a different timezone.

    The sender's Outlook calendar also independently showed the meeting at 2 PM Eastern, confirming the intended instant.

  13. kirkawolff commented on Sep 14, 2026

    @kirkawolff
    kirkawolff
    on Sep 14, 2026

    When will this be fixed? MS calendar ICS imported invites always default to the local timezone.

  14. acq23 commented on Oct 28, 2026

    @acq23
    acq23
    on Oct 28, 2026

    I've been in late to an intercontinental meeting because of this.
    It blows my mind that a developer refuses to fix a bug on a feature that is essential for a calendar.
    And this since the beginning of the fork because bugs related to ICS import and DST management are there since, at least, Feb 28, 2024.
    Plus on #165 on Mar 14, 2025 a fix have been announced for the following release and nothing came into production.
    On 2026 the following actions on the same bug report have been done:
    naveensingh
    added confirmed accepted and removed confirmed
    on Jan 27

    naveensingh
    removed accepted
    on Jul 14

    Does anyone knows trustable fork of simple calendar that has not this problem or other calendar trustable apps? I need caldav integration at least via DAVx5 and Android 9 compatibility.

  15. acq23 commented on Oct 28, 2026

    @acq23
    acq23
    on Oct 28, 2026

    @naveensingh Etar calendar just works fine on this matter: go and look at its code.

  16. vepain commented on Oct 29, 2026

    @vepain
    vepain
    on Oct 29, 2026

    Bug also here.

    In addition, when I export the ICS and import into a google calendar via thunderbird, both thunderbird and google calendar show me the events with a minus 1h shift, while the same re-imported events in Fossify Calendar are displayed at the correct time for the timezone...

    I checked every timezone parameters both from the OS and from the applications (linux and android). Only Fossify calendar differs in behaviour.

    It may help to know i am in timezone UTC + 1, so it can explain why the events received a minus 1h.

    Android 10
    Fossify calendar 1.12.0

  17. openfnord commented on Oct 29, 2026

    @openfnord
    openfnord
    on Oct 29, 2026
    Author

    They should fix it. Who cares for updated translations when essential features of a calendar go wrong!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is not working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions