Ich habe ein Problem mit der Zeitumstellung. Da das Problem aber vielleicht nicht nur Linux betrifft, stelle ich es hier zur Diskussion:
Trage ich mit/in Lightning einen Termin in den Kalender (lokale ics-Datei) ein, enthält dieser eine Info zur Zeitzone:


Soweit, so schön. Leider sieht derselbe Termin nach dem Synchronisieren mit dem PDA (mit OpenSync) jedoch so aus:

Wie man sieht, fällt die Angabe der Zeitzone fällt beim Synchronisieren irgendwie weg. Lightning interpretiert anschließend das Fehlen der Angabe als UTC, und der Termin wird trotzdem korrekt angezeigt.

Das geht aber nur solange gut, wie es sich um einzelne Termine handelt!

Wiederholende Termine, die über den (die) Tag(e) der Zeitumstellung hinweg gehen, verrutschen dagegen um eine Stunde, sie werden von Lightning falsch angezeigt.

Jetzt kommt aber ein großes AAABER:

korganizor hat damit kein Problem. Ich kann dieselbe ics-Datei, die Lightning benutzt, an korganizor verfüttern, und dann werden auch die Termine, die Lightning falsch anzeigt, von korganizor richtig angezeigt. Anscheinend errechnet korganizor die Startzeit eines sich wiederholenden Termins anders als Lightning.

Könnte man da als Entwickler nicht ansetzen und sich die Berechnung der Anfangszeiten von korganizor "abgucken"? Oder gibt’s eine andere Lösung zu diesem Problem? Ich habe bereits versucht, in Lightning UTC als Zeitzone einzutragen, aber das geht gar nicht.

Falls jemand eine Lösung für dieses Problem kennt, wäre ich sehr, sehr, sehr, sehr dankbar für entsprechende Hinweise. Zur Zeit gibt es für mich nämlich nur eine Möglichkeit, meine Terminkalender auf dem PDA und dem Desktop korrekt synchron zu halten, und das ist manuell, mit doppelter Buchführung. Das ist alles andere als befriedigend.

Ein Termin kann entweder UTC sein ("Z" am Ende) oder in einer definierten Zeitzone ("TZID=Europe/Berlin"), nicht aber beides gleichzeitig wie in diesem Fall. Das Verhalten daher undefiniert. Versuch es doch mal indem du manuell des "Z" am Ende vor dem synchronisieren entfernst.

Bei wiederholenden Terminen mit einer fixierten Zeit in UTC ist es wie folgt: UTC kennt keine Sommer- oder Winterzeit, deine lokale Zeitzone aber schon. Europe/Berlin wechselt z.B. zwischen UTC+1 und UTC+2. Ein Termin "20100402T1030000Z" findet also in der Winterzeit um 11:30, in der Sommerzeit um 12:30 statt.

Dies ist das Ergebnis, wenn ich einen entfernten Kalender von Lightning in eine lokale Datei exportieren lasse:



Und so sieht es aus, wenn ich denselben Kalender von korganizor exportieren lasse:



Beide speichern die Zeiten mit einem abschließenden "Z" ab. Wenn das falsch ist, machen beide Programme denselben Fehler.

Warum? Sehen doch beide korrekt aus. Datum und Zeit ist jeweils in UTC angegeben und damit gültig. Aber UTC + Zeitzone wie in deinem ersten Beispiel ist ungültig.

Ah, jetzt habe ich gesehen, was Du meinst. Ja, Du hast Recht: das war ein Fehler meinerseits, verursacht durch unsauberes Ausschneiden mit der Maus.

Also noch mal, um alle Klarheiten zu beseitigen. In der Datei sieht ein solcher Eintrag vor dem Synchronisieren so aus:



Nach dem Synchronisieren:



Wie gesagt: bei einzelnen Terminen ist das egal. Probleme machen nur wiederkehrende Termine, die über die Zeitumstellung hinweg bestehen, wobei es aber auf das Programm ankommt, mit welchem die Kalenderdatei betrachtet wird: Lightning verschiebt Termine, Korganizer nicht.

Ob das Verschlucken der Zeitzonen-Info ein Fehler des Synchronisierungs-Programms (in diesem Fall OpenSync) ist oder vielleicht eine gewollte Eigenschaft, kann ich nicht beurteilen, aber Korganizer ist doch der Beweis, daß sich ein Programm durch das Fehlen der Info nicht aus dem Tritt bringen lassen muß, wenn es um Berechnung der Anfangszeiten von sich wiederholenden Terminen geht und ein Wechsel Zeitzonen dazwischen liegt. Es wäre halt sehr schön, wenn Lightning diese Berechnung ebenfalls richtig machen würde.

Aus meiner Sicht liegt der Fehler demnach bei Korganizer, da dieser offenbar UTC-Zeiten falsch interpretiert. Die koordinierte Weltzeit (UTC) wurde eben definiert um immer einen festen Zeitbezug zu haben, unabhängig von Zeitzonen oder Sommerzeit/Winterzeit. Die lokale Zeit ist dann wieder abhängig von Zeitzonen und Sommerzeit/Winterzeit.

Ich glaube nicht, daß Korganizer hier einen Fehler macht. Ich glaube eher, es korrigiert nur einen Fehler, denn es geht hier nur um wiederkehrende Termine, deren Zyklus über die Zeitumstellung hinweg besteht. Und ich kenne keinen regelmäßigen Termin, der im Sommer eine Stunde eher beginnt als im Winter, gemessen an der lokalen Zeit. Und genau darauf kommt es doch an: wenn ich im Februar einen wöchentlichen Termin anlege, z.B. jeden Montag um 9.00h, darf dieser Termin im April, nach der Umstellung auf die Sommerzeit nicht plötzlich Montags um 8.00h oder 10.00h im Kalender stehen. Also ist es doch eigentlich logisch, sich den ersten Termin dieses Zyklus anzusehen, und die Folgetermine anhand der dort definierten Wiederholungsregel zu berechnen, unabhängig von den Zeiten, die bei den einzelnen Terminen eingetragen sind, mit einer einzigen Ausnahme: einzelne Termine, die aus dem Zyklus gestrichen oder verschoben wurden, z.B. wegen Feiertagen. Diese müssen in einzelne Termine umgewandelt werden.

Generell werden einzelne Termine ohne Wiederholung von Lightning ja richtig behandelt. Nur bei Zyklen kommt Lightning anscheinend ins Stolpern.

Bei wiederholenden Terminen in lokaler Zeit oder einer bestimmten Zeitzone gebe ich dir Recht. Im obigen Beispiel geht es aber nicht um einen solchen Termin, sondern um einen wiederholenden Termin in UTC und deswegen bleibe ich bei meiner Meinung Beispiel:


Der wiederholende Termin findet immer um 20:00 Uhr Ortszeit Berlin statt, unabhängig davon ob dort gerade Sommer- oder Winterzeit ist. In anderen Zeitzonen kann sich die Zeit aber durchaus ändern. In New York hat die Sommerzeit bereits vor zwei Wochen begonnen, bei uns startet sie erst nächstes Wochenende. Deshalb ist aus deren Sicht der Termin aktuell um eine Stunde verschoben. Erst wenn bei beiden die Sommerzeit gilt ist der Termin wieder an der ursprünglichen Zeitposition.


Der wiederholende Termin findet immer um 20:00 Uhr lokale Ortszeit statt, unabhängig von der Zeitzone. Es ist also egal ob du in gerade in Sydney, Berlin oder New York bist.


Der wiederholende Termin findet immer um 20:00 Uhr koordinierte Weltzeit (UTC) statt. Abhängig von der lokalen Zeitzone, Sommer- und Winterzeit ändert sich der Offset zu UTC. Für einen Nutzer in der Zeitzone Berlin wechselt der Termin damit zwischen 21:00 Winterzeit (UTC+1) und 22:00 Sommerzeit (UTC+2).

Das eigentliches Problem ist damit der Datenverlust bei der Synchronisation mit dem PDA. Denn damit wird aus dem Termin mit Zeitzone ein Termin ohne Zeitzone in UTC. Und dafür gilt eben ein anderes Verhalten.