Import von ICS-Dateien ohne Zeitzonenangabe in Thunderbird-Kalender um 1 Std. (MEZ) bzw. 2 Stunden (MESZ) nach hinten verschoben

  • Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:

    • Thunderbird-Version: 52.1.0
    • Lightning-Version: integrierter Kalender
    • Betriebssystem + Version: Windows 7 und Win 10 Professional
    • Eingesetzte Antivirensoftware: Kaspersky AV 2017
    • Firewall (Betriebssystem-intern/Externe Software): intern


    Wenn ich folgende ICS-Datei (von spontacts) ohne Zeitzonenangabe in den Thunderbird-Kalender (dieser ist ausschließlich mit einem Google-Kalender verknüpft) importiere, geht er davon aus, dass sie in UTC ist und verschiebt sie um eine oder zwei Stunden nach hinten.

    Ist jetzt die ICS-Datei nach der "Norm"* falsch oder macht Thunderbird da einen Importfehler?


    * https://www.ietf.org/rfc/rfc2445.txt Deren Inhalt versteh ich aber nicht vollständig. :-(


    Wenn ich dieselbe ics-Datei nämlich online in den Google-Kalender importiere, stimmt die Zeit nach MEZ oder MESZ.


    In Thunderbird-Kalender, im Google-Kalender und im System steht Berlin als Zeitzone eingetragen.


    Die Hinweise aus Bei ICS-Import falsche Uhrzeit in Lightning [erl.]

    haben bei mir leider nicht geholfen.


    Freue mich sehr auf Tipps hier aus der Community.


    Lisa


    Hier ist der Inhalt der Datei:

    2 Mal editiert, zuletzt von LilaLisa81 ()

  • Ist jetzt die ICS-Datei nach der "Norm"* falsch oder macht Thunderbird da einen Importfehler?

    Hallo Lisa :)


    ich vermute ersteres.

    Hier ist der Inhalt der Datei:

    Ich habe das einmal verglichen mit einem Termin, den ich mir vor einiger Zeit aus OL geschickt hatte. Die ICS-Datei sieht auszugsweise folgendermaßen aus:

    In Deiner ICS-Datei finde ich keinerlei Angaben zur Zeitzone (TZ = Time Zone). Dann ist es für mich nachvollziehbar, dass TB von UTC ausgeht.

    //www.ietf.org/rfc/rfc2445.txt Deren Inhalt versteh ich aber nicht vollständig.

    Suche nach time zone. In Abschnitt 4.2.19 finde ich z.B.

    Parameter Name: TZID

    [...]

    The parameter MUST be specified on the "DTSTART", "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a DATE- TIME or TIME value type is specified and when the value is not either a UTC or a "floating" time.

    Gruß Ingo

  • geht er davon aus, dass sie in UTC ist und verschiebt sie um eine oder zwei Stunden nach hinten.

    Abgesehen vom fehlenden BEGIN:VCALENDAR (kopierfehler?) fällt an deinem Termin auf, dass die Zeit in sogenannter Floating-Time angegeben ist. Floating Time (im deutschen Thunderbird "Lokale Zeit") ist keine Zeitzone und nicht identisch mit UTC. In meinen Tests hat der Import dahingehend jedoch funktioniert.


    Floating-Time-Termine finden in allen Zeitzonen zur selben Uhrzeit, aber zu ggf. unterschiedlichen Zeitpunkten statt (z.B. beginnt und endet ein ganztägiger Termin immer um 0 Uhr und ist entsprechend in Floating-Time). Aus dem Kontext würde ich jedoch vermuten, dass der Termin eigentlich eine Zeitzone haben sollte und damit inhaltlich falsch ist. Google unterstützt kein Floating-Time (außer bei ganztägigen Terminen), daher ist es wenig verwunderlich, dass die Zeit dort falsch (bzw. "fälschlicherweise richtig") interpretiert wird.

  • Abgesehen vom fehlenden BEGIN:VCALENDAR (kopierfehler?)

    Das ist Thunder passiert, der meinen anfängerhaft einfach als Text eingefügten Inhalt der ics-Datei dankenswerterweise zu Code und meinen Beitrag insgesamt etwas umformatiert hat.


    fällt an deinem Termin auf, dass die Zeit in sogenannter Floating-Time angegeben ist.

    Woran erkennst du das?


    In meinen Tests hat der Import dahingehend jedoch funktioniert.

    Kannst du eine Beispieldatei in Floating Time und ohne TZID posten, die bei dir funktioniert?

    Parameter Name: TZID

    [...]

    The parameter MUST be specified on the "DTSTART", "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a DATE- TIME or TIME value type is specified and when the value is not either a UTC or a "floating" time.

    Gruß Ingo

    Hi Ingo, danke. Leider bin ich auch nur ne einfache doofe Anwenderin, die gerne ihre Termine aus spontacts in den Kalender importieren möchte, ohne erst die halbe RfC 2445 durcharbeiten zu müssen, um dann festzustellen, dass ich jede ics von spontacts erst umschreiben müsste. Dafür ist mir meine Lebenszeit zu kostbar. Da ist ja das manuelle Verschieben des falschen Eintrags zigmal schneller.

    "Der Parameter TZID (Zeitzonen-Kennung) MUSS für die Eigenschaften von "DTSTART", "DTEND", "DUE", "EXDATE" und "RDATE" spezifiziert werden, wenn entweder ein Datums-/Zeit-Wert oder ein Zeit-Wert spezifiziert ist und wenn der Wert auch nicht eine UTC- oder eine "fließende" Zeitangabe ist. " "DUE"? "EXDATE"?? und "RDATE"??? Kann ich sicher alles nachlesen, ist mir aber leider zu nervig.

    Das versteh ich alles nicht so hundertprozentig, Bei Kalendereinträgen, die DTSTART oder DTEND enthalten, gehe ich davon aus, dass IMMER Datum und Uhrzeit angeben sein müssen. Und ob Zeit fließend ist oder nicht, gemahnt eher an philosophische Betrachtungen.


    ----


    Heißt also im Klartext, dass der Programmierer von oder für "spontacts" (dem Anbieter dieser ics-Datei) die Regeln für ICS-Dateien nicht vollständig berücksichtigt hat, dass er den Parameter TZID eigentlich spezifizieren müsste, es aber nicht tut, sodass falsche Einträge beim Import zustande kommen, richtig? Zur grundsätzlichen Fehlerbehebung muss ich also spontacts mailen, richtig?

  • Heißt also im Klartext, dass der Programmierer [...] den Parameter TZID eigentlich spezifizieren müsste, es aber nicht tut

    Hallo Lisa :)


    ja, so hatte ich das verstanden. Allerdings muss ich zugeben, dass mir der Begriff FloatingTime dabei nicht klar war und TB das "lokale Zeit" nennt. Insofern habe ich da wieder etwas gelernt ;)


    Ich frage mich jetzt auch, welche Zeitzone die Betreiber von Spontacts angeben sollten. Ich kenne den Dienst nicht. Es könnte aber sein, dass er von Leuten aus verschiedenen Zeitzonen genutzt wird. Gut, dann könnten sie vielleicht die Zeitzone aus dem Browser auslesen. Allerdings hat ein Test von generalsync mit lokaler Zeit ja wohl funktioniert.


    Gruß Ingo

  • Kannst du eine Beispieldatei in Floating Time und ohne TZID posten, die bei dir funktioniert?

    Deine Datei mit hinzugefügtem BEGIN:VCALENDAR ist bei mir korrekt als Floating-Time importiert worden, der für den Benutzer sichtbare Unterschied ist die Angabe der Zeitzone "Lokale Zeit" wenn im Termin-Dialog Einstellungen|Zeitzone anzeigen aktiv ist. Natürlich ist der Termin dennoch "falsch", da er von Spontacts mit falschen Daten generiert wurde. Dementsprechend zeigt er nur dann die "korrekte" Zeit, wenn du in der richtigen Zeitzone bist ;)


    Da der Dienst ja auch den Ort zu erfassen scheint, sollte er m.E. die Zeitzone des Zielorts nehmen und gut. Ansonsten ist es auch in Ordnung, ein "Z" an die Startzeit anzuhängen und damit eine Angabe in UTC zu machen, ohne zu spezifizieren in welcher Zeitzone diese angezeigt werden soll. Derzeit scheint der Anbieter die Eingabe aus der Zeitzone des eingebenden Benutzers korrekt in UTC zu wandeln, die Zeitzoneninformation anschließend zu verwerfen und das Ergebnis als Floating-Time wieder auszugeben. Damit ergibt sich ein Floating-Time-Termin zu der Uhrzeit, zu der der Termin in Greenwich stattfinden würde.


    Da ist ja das manuelle Verschieben des falschen Eintrags zigmal schneller.

    Wenn du manuell verschieben willst, solltest du auf jeden Fall auch die Zeitzone ändern, sonst werden die Termine automatisch "falsch" verschoben, wenn du die Zeitzone wechselst.


    Für deinen Fall vermutlich bequemer: hänge an die Werte von DTSTART und ggf. DTEND (falls vorhanden) einfach ein "Z" an. Bessere Texteditoren können das per Suchen/Ersetzen. Dann sind die Termine nicht mehr Floating-Time und sollte "wie gewollt" importiert werden (19:30 passt, denke ich?). Da keine Zeitzone angegeben ist, wird Thunderbird beim Bearbeiten jedoch UTC/GMT als Zeitzone anzeigen – und die entsprechend "verschobenen" Zeiten.

    Die übrigen iCal-Schlüsselwörter auf die du dich beziehst sind nur für komplexere Termine relevant, z.B. bei Terminen, die sich wiederholen.