Hallo ich habe dier Caldav Integration genutz um den Synoly Kalender einzubinden. Es sind mehrere Kalender die für versch. Nutzer freigegeben sind. Manche werden Problemlos eigebunden aber mansche ahebn wohl einen Fehler mit:
vobject.base.ParseError: "In transformToNative, unhandled exception on line None: <class 'ValueError'>: at least one component is needed (<VTIMEZONE| [<TZID{}Europe/Berlin>]>)"
mit Hilfe von AI habe ich schon die Zeitzone in die configurationsyml übernommen, so dass die Zone global ist. Hat leider nur kurz geholfen. Scheinbar sendet Synology einen unvolständigen Format aus dem Kalender:
BEGIN:VTIMEZONE
TZID:Europe/Berlin
END:VTIMEZONE
Das kann ich durch exportieren & löschen + wieder importieren lösen (Kalender funktioniert) aber sobald ein neuer Termin in den Kalender eingefügt wird, wird das wieder angehängt. > Kalender hat wieder den Fehler.
Habe jetzt auch schon mit docker versucht einen Proxy zum filtern zu nutzen. Der filtern ist:
Ich habe mit Python ein Tool geschrieben, dass sich für einen Verein um Raumreservationen kümmert.
Ich kann dir nicht spezifisch bei deinem Client weiterhelfen, was ich dir aber sagen kann, ist wie ich Events pushe und was ich verwende, um sie zu pullen und korrekt zu parsen.
Meine gepushten Events sehen so aus:
Der Termin wird korrekt als 00:00-10:00 von Synology geparst.
Beim Pullen mache ich Folgendes:
Auschnitt aus einem raw-pull:
`BEGIN:VTIMEZONE`
`TZID:Europe/Amsterdam`
`TZID-ALIAS-OF:Europe/Brussels (irrelevant für parsing)`
`ganz viel RDATE`
`END:VTIMEZONE`
`BEGIN:VEVENT`
`SUMMARY:Bestätigt - test anfrage`
`DTSTART;TZID=Europe/Amsterdam:20260115T090000`
`DTEND;TZID=Europe/Amsterdam:20260115T100000`
`DTSTAMP:20260104T194259`
`UID:<UID von synology oder wenn event über push erstellt die von dir>`
`END:VEVENT`
Synology liefert teils kaputte VTIMEZONE-Blöcke. Du kannst aber den String hinter “TZID=” auslesen, diesen behalten und in einer Zeitzonen-Bibliothek suchen, in Python: pytz.timezone() oder zoneinfo.ZoneInfo(“Europe/Berlin”). Also nicht nach VTIMEZONE parsen, bzw. nicht nur, sondern auch direkt nach TZID.
Heuristik zum Erkennen „kaputt“: VTIMEZONE enthält keinen BEGIN:STANDARD und keinen BEGIN:DAYLIGHT → weg damit.
was ich absichtlich vermieden habe:
„Zeitzone global setzen“ und hoffen, dass es passt: das kaschiert das Problem nur kurz.
Timeshift-Hacks (+/- 1–2h), weil das auf anderen Clients kaputt geht.