Serielle Termine mit Thunderbird 24 Lightning und Horde Kronolith via Caldav bei Sommer-Winter Zeitumstellung

Abstract

Im Rahmen meines Horde Webmail Updates und meinen Tests mit Remote Kalendern via CALDAV an Horde Kronolith, habe ich ein fehlerhaftes Verhalten von Thunderbird Kalender Lightning feststellen müssen.

Serielle Termine mit Thunderbird 24 und Horde Kronolith

Im Rahmen meines Horde Webmail Updates und meinen Tests mit Remote Kalendern via CALDAV an Horde Kronolith, habe ich ein fehlerhaftes Verhalten von Thunderbird Kalender Lightning feststellen müssen.

Trägt man in Lightning einen seriellen (z.B. wöchentlichen Termin) in einen remote CALDAV Kalender mit Horde Webmail 5.2.1 ein, wenn der Zeitraum sich über sich über die baldige Sommerzeit Winterzeit Umstellung erstreckt. Der Termin wird in der Gegenwart (Sommerzeit) noch mit den richtigen Anfangs- und Endzeiten angezeigt. In der Zukunft (Winterzeit) erscheinen die Anfangs- und Endzeiten jedoch mit einem Zeitversatz von einer Stunde.

Im Horde Kalender (Kronolith) werden alle Termine immer richtig angezeigt und auf einem Android Smartphone via active sync auch. Intern verwendet die neue Kronolith Version UTC (zumindest wenn man es so einstellt). Aber selbst wenn man dies unterlässt, ändert das nichts am Verhalten von Lightning. Die Konfiguration von UTC in Kronolith ist an sich eine vernünftige Entscheidung, da diese eine intelligente Grundlage zur Berechnung von Terminen in allen Zeitzonen liefert. Seine persönliche Zeitzone kann im Profil von Kronolith und Lightning eingestellt werden (z.B.: Europe/Berlin).

Intern scheint nun folgendes beim Erstellen eines seriellen Termines via Lightning abzulaufen: Der Termin wird erstellt und mit Horde per caldav abgeglichen. Dabei werden die Zeiten in UTC umgerechnet. Es scheint, dass Lightning nun versucht besonders clever zu sein. Es zeigt die Anfangs- und Endzeiten des Termins in der Zukunft mit einem Zeitversatz von einer Stunde an.

Die Tests habe ich auf Ubuntu precise 12.04 durchgeführt und auf einem Windows 7 verifiziert: Das Verhalten blieb immer das Gleiche.

Nun könnte man dies als kosmetisches Problem begreifen, das im schlimmsten Fall den Nutzer verwirrt. Deshalb habe ich meine Systemzeit kurz in die Zukunft (nach der Umstellung) gestellt. Lightning zeigt leider die Anfangs und Ende Zeiten auch dann nicht richtig an. Im Grunde ist das auch nachvollziehbar; es hat sich zwar die Zeit verändert aber nichts am Termin selbst. Das heißt, selbst bei einem sync gibt es keinen wirklichen Update für den Termin. Ab diesem Punkt wird es also problematisch, denn der serielle Termin ist im Lightning Kalender nun wirklich falsch.

Zeitzonen und überhaupt Kalender sind ein komplexes Thema. Auch das dargestellte Problem scheint in anderen Versionen schon mal gefixed worden zu sein. Insgesamt scheint die neue Lightning Version 2.6 nicht der große Wurf gewesen zu sein. Ich habe dazu einen schon älteren Bug Report bei Mozilla ergänzt. Ich möchte auch nicht meine Hand dafür ins Feuer legen, dass alle Versionen von Lightning auf allen Betriebssystemen dieses Verhalten zeigen. Aber dieser Fehler scheint mir doch diesen Blog wert zu sein, damit andere Betroffene nicht auch noch endlos suchen müssen.

Update

Das Problem scheint "per Design" zu sein. Im Grunde ist die Auffassung von Lightning genauso richtig wie die Auffassung von Kronolith. Der unerwünschte Effekt tritt beim sync über Caldav auf, ein Event wird nach dem Erstellen resynced an Lightning, dabei wird die Ersteller Zeitzone nicht mehr mitübertragen. der Event ist nun in UTC. Das macht auch weitgehenst Sinn, denn der Event soll ja in der Zeitzone des Clients angezeigt werden. ( es können ja durchaus mehrere Clients in diversen Zeitzonen auf den selben Event zugreifen müssen ), will heißen der Client soll aus den UTC Zeiten an Hand seiner eigenen eingestellten Zeitzone die richtige Anzeige erstellen. Das tut Lightning ja auch völlig richtig für die gegenwärtige und zukünftige Zeit ( zb nach einer Zeitumstellung ). Das wirkliche Problem ist nun das der Event aber weder vom Client noch vom Server automatisch angepasst wird. Zu Deutsch man muss seine Serien Termine schlichtweg selbst per Hand anpassen nach einer Zeitumstellung, d.h also im Client den Serien Event von UTC wieder auf z.B Europe/Berlin einstellen, sync/resync dann sollte er wieder richtig angezeigt werden, zumindest für die Zeit bis zur nächsten Zeitumstellung.

Als Workaround kann man die alte Webdav ics Methode nutzen, welche aber in meinen Setup inakzeptabel langsam ist, bei dieser Methode existiere der Fehler offensichtlich auch schon ,wurde aber von den Horde Entwicklern gefixed, siehe https://bugzilla.mozilla.org/show_bug.cgi?id=520843 , wenn ich das richtig interpretiere. Bei der reinen Webdav Übertragung dürfte dies auch einfacher gewesen sein, denn nach meiner Info wird dort schlicht der ganze Kalender übertragen, daher kann es eigentlich kein Abweichungen mit dem Client in einzelnen Events geben.

UPDATE II

Ich bin jetzt vorläufig bei der Webdav ICS Methode geblieben, da Fehler in Termin Serien für mich nicht akzeptabel sind, außerdem ist ein Funktionieren der Versendung von Termineinladungen via Mail für mich ebenfalls unerlässlich ( diese Feature wird soweit ich das verstanden habe aber noch nachgerüstet, irgendwann ). Leider werden Teilnehmer eines Termins der über Thunderbird Lightning mittels ICS erzeugt wurde derzeit noch nicht in Kronolith angezeigt ( das kann ich aber verschmerzen ). Um die Performance der ICS Webdav Methode zu verbessern, sollte man beim Anlegen des Kalenders in Lightning offline caching einschalten und im virt Host für Horde für Thunderbird Keep Alive abschalten, z.B mit BrowserMatch "Thunderbird" nokeepalive . Noch ein kleiner Tipp, die Anzeige von Terminerinnerungen ( reminders ) kann lästig werden wegen sync Problemen , man kann die Anzeige für abgelaufene Erinnerungen in den Einstellungen von Thunderbird / Lightning jedoch abschalten. Wird man ohnehin zusätzlich per Mail z.B von Horde an Termine erinnert sollte dies bei der täglichen Arbeit kein Problem darstellen.

hier ein paar Bilder dazu

FINALES UPDATE

Meine Tests ergaben dass das Problem in Horde 5.1.6 gefixed wurde ( also bitte verifizieren dass man auch tatsächlich mind. die Version nutzt), Hauptursache waren Probleme mit dem TZDATA file das per Standard eigentlich über FTP heruntergeladen werden sollte, es mag also besser sein diese Datei per Hand herunterzuladen und in Horde einen lokalen file Pfad dafür zu konfigurieren.

/usr/share/horde/config/conf.php

$conf['timezone']['location'] = 'file:///usr/share/horde/tzdata-latest.tar.gz';

Möglicherweise ist das Problem aber noch nicht völlig ausgestanden, es gibt bereits einen weiteren Test fix

https://github.com/horde/horde/compare/6a0c685fa99b8cde442d1f68f39798214d73ed9e...111a5bdba46a28674b939c4e2ba5485c98c3f5f7

siehe Horde Mail List

http://lists.horde.org/archives/horde/Week-of-Mon-20140310/050928.html

Robert Schetterer, 17. October 2013