ICS Bug timezone

[wilf80]

Environment

• TaskNotes: 3.25.3 (current release)
• Obsidian: 1.10
• OS: Linux (Fedora 43)
• System time zone: Europe/Zurich (DST active when testing)
• Calendar source: Infomaniak ICS subscriptions

Summary

Since the recent change related to “local time,” ICS events that include a TZID (e.g. Europe/Zurich) are rendered +2h ahead in the TaskNotes calendar views.
Example: an event 09:45–10:45 in Europe/Zurich appears as 11:45–12:45 in TaskNotes.

This did not happen before; after the last fix following my previous report, “local time” stopped working for me and the +2h offset appeared systematically.

Minimal ICS sample

BEGIN:VEVENT
CREATED:20251010T171020Z
DTSTAMP:20251011T053325Z
SUMMARY:Meeting
TRANSP:OPAQUE
LOCATION:Zurich
DESCRIPTION:
DTSTART;TZID=Europe/Zurich:20251013T094500
DTEND;TZID=Europe/Zurich:20251013T104500
SEQUENCE:3
LAST-MODIFIED:20251011T070016Z
UID:ef72e2dd-5e7c-40a9-8984-7b7f67aebbe5
END:VEVENT

BEGIN:VEVENT
CREATED:20251010T171039Z
LAST-MODIFIED:20251010T171052Z
DTSTAMP:20251010T171052Z
SUMMARY:Meeting 2
DTSTART;TZID=Europe/Zurich:20251013T114500
DTEND;TZID=Europe/Zurich:20251013T134500
TRANSP:OPAQUE
UID:6a6c3c71-b9d5-4740-81e9-2985de0b177b
END:VEVENT

Expected vs Actual

• Expected: Show 09:45–10:45 for the first event (respecting TZID=Europe/Zurich).
• Actual: TaskNotes shows 11:45–12:45 (+2h).

What I’ve already tried (local tests/patches)

To help pinpoint the root cause, I tested several focused changes locally (without success end-to-end):

1. Avoid forcing UTC in ICS → Date conversion

   • In the bundle, icalTimeToISOString(...) ended with return new Date(unix*1000).toISOString().
   • I changed it to return a Date object instead of .toISOString() (so no Z).
   • Result: still observed +2h in the calendar.

2. Don’t append Z in “floating” parser

   • In static parseICSDate(t), the minified code appended Z in a template literal.
   • I removed the Z so that floating/local times stay local.
   • Result: still +2h in the calendar.

3. FullCalendar timezone

   • Explicitly set timeZone to Europe/Zurich (and also tried local) on the TaskNotes calendar instance.
   • Result: no effect on the +2h shift.

4. Event-level transforms

   • Injected a eventDataTransform that converts any ICS event whose start/end end with Z into local Date objects (strip Z, use new Date(…)).
   • Also tried wrapping the service’s getAllEvents() to normalize ICS start/end.
   • Result: still +2h; suggests another path later reintroduces UTC or bypasses transform.

5. Direct event-construction point

   • At the point where TaskNotes builds the FullCalendar event objects with extendedProps:{ eventType:"ics", icsEvent:... }, I replaced:

     start:n.start, end:n.end
     

     with conditional conversion from "...Z" → new Date(...).

   • Result: still +2h in the final render in my setup.

Hypothesis

Some ICS code path still converts the localized ICS time (TZID=Europe/Zurich) into an ISO string with Z (UTC), which FullCalendar then re-displays in the local browser zone, adding +02:00 and causing the visible shift. This likely happens after recurrence expansion or in a code path not covered by the simple toISOString()/parseICSDate edits above.

How to reproduce (on my side)

1. Add an Infomaniak ICS subscription containing an event with DTSTART;TZID=Europe/Zurich:20251013T094500.
2. Open TaskNotes Calendar (Advanced or Bases).
3. The event displays as 11:45–12:45 instead of 09:45–10:45.

Useful console checks (dev tools)

• My browser environment reports:

  • Intl.DateTimeFormat().resolvedOptions().timeZone → Europe/Zurich
  • new Date().getTimezoneOffset() → -120 (during DST)

• In my tests, some calls to the internal ICS service returned 0 items depending on the view lifecycle, but the rendered calendar still showed the +2h.

Request

• Could you please review the ICS → event pipeline to ensure that:

  • Times with an explicit TZID are kept in that zone when transformed, not converted to ...Z unless truly UTC.
  • If emitting ISO strings, prefer offset form (2025-10-13T09:45:00+02:00) or plain Date objects, rather than .toISOString() (which forces Z).
  • Confirm the calendar instance is initialized with an appropriate timeZone (local or the user’s IANA zone) and that later transforms don’t override it.

• If there’s a known fix planned for v4 that touches ICS/TZ handling, I’m happy to test a beta (e.g., via BRAT). Otherwise I can test a small patch on 3.25.x.

Thanks a lot! I can provide additional logs or test builds if that helps.

[wilf80]

Environment

• TaskNotes: v3.25.4 (latest)
• Obsidian: 1.10.1
• OS: Fedora 43
• Local timezone: Europe/Zurich
• ICS providers tested: Infomaniak (primary), events also created via Thunderbird and Samsung Calendar (Android)

Summary
After the recent update, ICS events with TZID=Europe/Zurich render +1 hour ahead in the Agenda/Calendar on Oct 26, 2025 (the European DST end date). The same ICS file renders correctly for Europe/Berlin and Europe/Paris. This looks like a Zurich-specific DST-boundary conversion bug.

FYI, #849 (“ICS calendar timezone conversion for non-IANA timezones”) fixed the previous +2h issue for TZID=Zurich (non-IANA) and improved many cases, but this appears to be a remaining edge case with the IANA zone Europe/Zurich on the DST switchover day. ([GitHub][1])

Why this date matters
Europe ends DST on Sunday, October 26, 2025 (CET resumes at 03:00 local). Midday times that day should be UTC+01:00 across CET regions (Paris, Berlin, Zurich), i.e., they should all align.
Repro steps

1. Import the ICS below (single calendar is fine).
2. Open the Agenda/Calendar view.
3. Compare event times shown for Berlin, Zurich, and Paris entries.

Expected

• All three (Berlin/Paris/Zurich) show the same local clock times on 2025-10-26.

Actual

• Europe/Berlin: correct (keeps the hour)
• Europe/Paris: correct (keeps the hour)
• Europe/Zurich: +1h (e.g., an event saved as 16:00 renders as 17:00)

Additional observations

• From Infomaniak:

  • Event with Europe/Berlin: TaskNotes keeps the hour ✅
  • Event with Europe/Zurich: TaskNotes +1h ❌

• From Thunderbird:

  • Event saved as “Local time”: TaskNotes keeps the hour ✅

• From Samsung Calendar (Android):

  • Event saved in Central European Time (I picked Paris): Thunderbird shows Paris TZ (+1h there), TaskNotes keeps the hour ✅

Minimal ICS to reproduce

BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VEVENT
CREATED:20251026T065921Z
LAST-MODIFIED:20251026T070552Z
DTSTAMP:20251026T070552Z
UID:0174d9ed-0b83-41a0-be4d-85b08d281893
SUMMARY:Test 1
DTSTART:20251026T120000
DTEND:20251026T130000
SEQUENCE:1
X-MOZ-GENERATION:1
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER:-PT10M
DESCRIPTION:Test 1
END:VALARM
END:VEVENT
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-TZINFO:Europe/Berlin[2025b]
BEGIN:STANDARD
TZOFFSETTO:+010000
TZOFFSETFROM:+005328
TZNAME:Europe/Berlin(STD)
DTSTART:18930401T000000
RDATE:18930401T000000
END:STANDARD
... (large historical Berlin block unchanged)
BEGIN:DAYLIGHT
TZOFFSETTO:+020000
TZOFFSETFROM:+010000
TZNAME:(DST)
DTSTART:19970330T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETTO:+010000
TZOFFSETFROM:+020000
TZNAME:(STD)
DTSTART:19971026T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20251026T065921Z
LAST-MODIFIED:20251026T065921Z
DTSTAMP:20251026T065921Z
UID:3d73f4b4-4373-405d-a63e-3011e69e8e38
SUMMARY:Test 2
DTSTART;TZID=Europe/Berlin:20251026T140000
DTEND;TZID=Europe/Berlin:20251026T150000
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER:-PT10M
DESCRIPTION:Test 2
END:VALARM
END:VEVENT
BEGIN:VTIMEZONE
TZID:Europe/Zurich
BEGIN:STANDARD
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19961027T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19810329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20251026T065549Z
UID:ac1cb1d9-f07e-4a8b-ad1c-24e82b758370
SUMMARY:Test 3
DTSTART;TZID=Europe/Zurich:20251026T160000
DTEND;TZID=Europe/Zurich:20251026T170000
SEQUENCE:1
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER:-PT10M
DESCRIPTION:Test 3
END:VALARM
END:VEVENT
BEGIN:VTIMEZONE
TZID:Europe/Paris
BEGIN:STANDARD
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19961027T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19810329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20251026T070722Z
UID:61d5e2ec-6811-4e18-8b7b-0a29cdf5eafc
SUMMARY:Test 4
DTSTART;TZID=Europe/Paris:20251026T180000
DTEND;TZID=Europe/Paris:20251026T190000
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER:-PT10M
DESCRIPTION:Test 4
END:VALARM
END:VEVENT
END:VCALENDAR

What I’ve tried

• Changing Infomaniak calendar TZ to “Western Europe” → TaskNotes displays correctly.
• Using Local time in Thunderbird → TaskNotes displays correctly.
• Using Android Samsung Calendar with “Central European Time (Paris)” → TaskNotes displays correctly.
• Only Europe/Zurich exhibits +1h on this date.

Hypothesis
A remaining edge case in the ICS → UTC → local conversion path for Europe/Zurich on the DST boundary (Oct 26, 2025). Berlin/Paris and “Local time” likely take a different code path (or different VTIMEZONE resolution) that yields the correct post-switch offset. Note: Europe switches to CET at 03:00 local; at 12:00/14:00/16:00 that same day, offset should be +01:00 for all three cities.

Request

• Could you verify Europe/Zurich with the ICS above on 2025-10-26 and check whether ICAL.Time/toUnixTime() is applying the pre-switch (+02:00) vs post-switch (+01:00) offset at midday?
• If helpful, I’m happy to run a test build or provide a screen recording.

Nice-to-have feature
Add a per-ICS subscription “Display timezone override” (e.g., force rendering in a user-chosen TZ). This would provide a safe fallback if upstream ICS TZs are odd or missing, and would have helped me avoid the offset temporarily.

Workarounds (for other users)

• Set the calendar TZ to “Western Europe” (or Berlin/Paris) in Infomaniak.
• Or create events with “Local time” in Thunderbird (works here).

Thanks a lot!