2h offset in Agenda/Calendar when ICS TZID is Zurich (Infomaniak). Android apps can’t avoid it; only workaround is Thunderbird “use local time”

[wilf80]

Title: –2h offset in Agenda/Calendar when ICS TZID is Zurich (Infomaniak). Android apps can’t avoid it; only workaround is Thunderbird “use local time”

Summary

Events from my Infomaniak calendar display two hours earlier in TaskNotes’ Agenda/Calendar views whenever the ICS uses a non-IANA timezone label Zurich (and no matching VTIMEZONE).
I tried creating/editing events with several Android calendar apps — they still end up with TZID=Zurich and TaskNotes shows a –2h shift during CEST. The only reliable workaround I’ve found is to edit the event in Thunderbird and set “use local time” (floating time), which then renders correctly in TaskNotes.

When the provider/ICS uses proper IANA tzids (e.g., Europe/Zurich), times are correct in TaskNotes.

Environment

• Obsidian: [e.g., 1.6.x] on [Linux Fedora 42 / Windows / macOS]
• TaskNotes: [e.g., 3.24.x]
• System timezone: Europe/Zurich (currently CEST, UTC+2)
• Calendar provider: Infomaniak (ICS subscription / CalDAV → ICS)
• Event source on mobile: multiple Android calendar apps tried; all produced TZID=Zurich in ICS (no VTIMEZONE)
• TaskNotes → Calendar Settings → Locale: tested fr-CH and empty (no effect)

Steps to Reproduce

1. On Android, create a timed event (e.g., 12:34–13:34) in a calendar synced with Infomaniak. The app only offers “Zurich” as the timezone when editing/creating.
2. Subscribe to the Infomaniak ICS in TaskNotes and open Agenda/Calendar.
3. Observe that most events with TZID=Zurich appear –2h (10:34–11:34 instead of 12:34–13:34) during CEST.

Control case: If the provider/ICS emits Europe/Zurich (or a valid IANA tzid with a proper VTIMEZONE), TaskNotes shows the correct times.

Expected Behavior

Events created in the Zurich timezone show at their actual local times (e.g., 12:34–13:34).

Actual Behavior

Events with TZID=Zurich (no VTIMEZONE) show two hours earlier in TaskNotes during CEST.

ICS Evidence (sanitized)

Problematic (offset –2h):

BEGIN:VCALENDAR
PRODID:-//Infomaniak//Calendar//EN
X-WR-TIMEZONE:Zurich
BEGIN:VEVENT
UID:[redacted]
DTSTART;TZID=Zurich:20251004T123400
DTEND;TZID=Zurich:20251004T133400
SUMMARY:Test event
END:VEVENT
END:VCALENDAR

Notes:

• TZID=Zurich is not an IANA tzid.
• There is no matching VTIMEZONE block defining “Zurich”.

Working (correct in TaskNotes):

BEGIN:VCALENDAR
PRODID:-//Infomaniak//Calendar//EN
X-WR-TIMEZONE:Europe/Zurich
BEGIN:VTIMEZONE
TZID:Europe/Zurich
... [standard/daylight rules] ...
END:VTIMEZONE
BEGIN:VEVENT
UID:[redacted]
DTSTART;TZID=Europe/Zurich:20251004T123400
DTEND;TZID=Europe/Zurich:20251004T133400
SUMMARY:Test event OK
END:VEVENT
END:VCALENDAR

What I’ve Tried

• Multiple Android calendar apps (changing app settings where possible) → still end up with TZID=Zurich in the ICS and –2h in TaskNotes during CEST.
• Removing/re-adding the calendar subscription in TaskNotes.
• Verifying OS timezone is Europe/Zurich.
• Changing TaskNotes “Calendar Locale” (language/format only) — no effect.
• Only workaround that works: open the event in Thunderbird and set “use local time” (floating). After that, TaskNotes displays the correct time.

Hypothesis

When TZID is a non-IANA label (e.g., Zurich) and there’s no defining VTIMEZONE, the parser seems to fall back to UTC (or otherwise fails to resolve the offset), causing a –2h shift during CEST.

Requests / Possible Improvements

• Graceful handling of non-IANA TZIDs without VTIMEZONE:

  • Fallback to the system timezone when tzid is unresolvable, or
  • Maintain a small alias map (e.g., Zurich → Europe/Zurich), or
  • Prefer a valid calendar-level timezone (X-WR-TIMEZONE) if present and IANA-valid.

• Per-calendar override: a setting in TaskNotes to force a timezone for a particular subscription feed.

• Optional “treat times as local (floating)” mode per calendar, to handle feeds that routinely emit ambiguous tz info.

Additional Info

• I can provide a minimal, anonymized ICS file privately if helpful.
• The issue affects timed events; all-day events look fine.
• Reproducible across newly created events.

Thanks a lot for considering this — happy to test a fix or debug builds if needed!

[callumalpass]

Thank you so much for the detailed description of this bug here, @wilf80 -- that's incredibly helpful. I'll try to get a fix for this soon.

[wilf80]

Update / Correction:
After further testing, the offset is consistently +2 hours (not –2). For example:

Source (Infomaniak / Thunderbird / Android): create a timed event 09:00–10:00, timezone set to Zurich (or edited in Thunderbird to “use local time” / floating).

TaskNotes (Agenda/Calendar): displays the event as 11:00–12:00 (i.e., +2 hours).

This happens whether the event is created on Infomaniak’s web UI, Thunderbird, or Android (all using “Zurich” or local/floating). My OS timezone remains Europe/Zurich.

Expected: 09:00–10:00
Actual: 11:00–12:00 (+2h)

Notes / hypothesis:

It looks like floating/local or Zurich-labeled times are being shifted forward by the local offset during conversion (possible double application of the offset or treating a local time as UTC, then adding +02:00 again).

Before the recent update, switching an event to local/floating in Thunderbird used to display correctly; now even floating shows +2h in TaskNotes.

Feature request (would solve this class of issues):
Add a per-calendar timezone override in TaskNotes so users can explicitly force interpretation as Europe/Zurich for feeds that emit ambiguous/non-IANA tz identifiers (e.g., “Zurich”) or floating times. This would provide a reliable fallback while the parser logic is refined.

Happy to test a build with extra logging.