ubuntuusers.de

Hallo!

Ich habe ein Problem, was ich auch schon mit der Version 22.04 hatte und keine Zeit und keine Idee fand, es zu lösen.

Hier hat jemand ein sehr ähnliches Problem geschildert:

https://forum.ubuntuusers.de/topic/evolution-exchange-uhrzeit-um-eine-stunde-ver/

Es MUSS mit der Zeitumstellung zu tun haben: Trage ich Termine für den Sommer ein, gibt es KEIN Problem.

Nun habe ich hier auch schon wieder einiges probiert und ich komme nicht weiter.

Vorgang:

Ich trage per Evolution einen Termin im privaten, ungesyncten Kalender für 8 Uhr ein. Alles prima: Termin 8 Uhr ...

Ich trage per Evolution und CalDAV bei meinem Provider, also mit Sync, einen Termin für 8 Uhr ein: Ergebnis sowohl in Evolution als auch beim CalDAV-Server meines Providers wird er für 7 Uhr eingetragen.

Ich habe alle Zeiteinstellungen überprüft, d.h. überall Berlin/Europe und korrekte Uhrzeiten gefunden.

Soweit ich auf demselben Rechner mittels Thunderbird Termine eintrage: Alles prima!

Genauso, wenn ich mittels Smartphone oder der Web-Anwendung beim Provider Termine eintrage.

Ich könnte jetzt Evolution sagen, ich wär in Portugal, dann klappt es zunächst, aber alle anderen, bereits eingetragenen Termine werden ebenfalls verändert - das ist keine Lösung.

Verdacht: Der Termin wird SOFORT - ohne JEDE Sync-Zeitverzögerung - falsch eingetragen. Deshalb gehe ich von einer Evolution-Fehleinstellung aus.

Ich habe mit timedatectl die folgende Ausgabe:

1
2
3
4
5
6
7
8

dorot@dorober:~$ timedatectl
               Local time: Fr 2025-02-07 18:59:39 CET
           Universal time: Fr 2025-02-07 17:59:39 UTC
                 RTC time: Fr 2025-02-07 17:59:39
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Auch Neustarts des gesamten Rechners und "systemctl restart systemd-timesyncd" brachten keine Besserung ...

Dankbar für Tipps!! ♥

Ich weiß nicht, ob ich mit meiner Vermutung richtig liege, aber versuche mal

 RTC in local TZ: no

auf yes zustellen.

Danke, aber es hatte keine Auswirkungen! Habe den Rechner einmal neugestartet, dennoch kein Effekt.

Und es wird auch davor gewarnt:

Warning: The system is configured to read the RTC time in the local time zone. This mode cannot be fully supported. It will create various problems with time zone changes and daylight saving time adjustments. The RTC time is never updated, it relies on external facilities to maintain it. If at all possible, use RTC in UTC by calling 'timedatectl set-local-rtc 0'.

Noch niemand mit derselben Problematik? Obwohl ich hier eine Standardsituation habe? Evtl taucht sie nur in dieser Kombi mit Mate auf?

Mir graut schon davor, ab Winterzeit wieder "improvisieren" zu müssen ...

Noch niemand mit derselben Problematik?

Nein.

Obwohl ich hier eine Standardsituation habe?

Das kann ich nicht beurteilen, da du keine Information gibst.

Evtl taucht sie nur in dieser Kombi mit Mate auf?

Das ist schon möglich. Wir sind hier bei Ubuntu.

Aber um dein Problem systematischer anzugehen, teile bitte mit, welche Version von Evolution du verwendest und wie du es installiert hast (deb, flatpak usw).

Einen Termineintrag im lokalen Kalender besagt gar nichts, da die dort gemachten Fehler nicht sichtbar werden. Wenn du einen Termineintrag bei einem Provider machst, interpretiert der Provider deine Angaben nach seiner Konfiguration und schickt die von ihm nach seiner Ansicht korrekt korrigierten Daten an den Client (Evolution) zurück.

Wenn du somit eine Stunde Zeitdifferenz feststellst, ist zu vermuten, dass du Einträge im UTC-0 Format versendest. Genauere Informationen bekommst du, wenn du dir den Termineintrag als Datei (z.B. .ics) abspeicherst und den Inhalt anschaust. Dort solltest du im "BEGIN/END:VTIMEZONE" Block sehen, welchen Zeitzone du konfiguriert hast. Speziell die Werte von TZNAME, TZOFFSETFROM, TZOFFSETTO sind interessant. Im "BEGIN/END:VEVENT" Block kannst du sehen, wie du die Zeiten (z.B. DTSTART, DTEND, DTSTAMP usw) eingetragen hast. Stehen dort Zeitzonen-Modifier? Enden die Zeiteinträge mit einen "Z"? Das hat alles nichts mit Evolution zu tun sondern sind RFC5545 Basics.

Abhängig von diesen Ergebnissen, kannst du über die GUI von Evolution deine zu verwendende Default-Zeitzone für Termine und Aufgaben setzen. Schau dazu im Menü unter "Bearbeiten" → "Einstellungen" → "Kalender und Aufgaben" → "Allgemein" → "Uhrzeit" nach, was du als Zeitzone bzw "Zweite Zone" usw definiert hast. Für einfache Zwecke sollte ein Haken bei "Zeitzone des Systems verwenden" gesetzt sein. Hast du eventuell auch mit den Anpassgliedern der Termindauer (Termine enden/starten ..) gespielt? Bei den Formaten für Datum/Zeit solltest du den Eintrag "Format der Region benutzen" stehen lassen.

Wenn du viel herum reist und in unterschiedliche Zeitzonen arbeitest, sind die Anpassungen ein wenig komplexer, je nachdem, was du angezeigt bekommen möchtest (Zeitzone UTC oder das des Aufenthaltsortes usw).

Aber liefere erst mal die Antworten auf die Basis-Fragen.

Danke!

Ich habe es wohl, wenn das angeboten wurde, als Snap installiert, ist jedenfalls "3.52.3-0ubuntu1". Bin den angebotenen Weg gegangen, also über "Anwendungszentrum".

Eine ics-Datei sind bspw so aus:

BEGIN:VCALENDAR
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
METHOD:PUBLISH
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19820329T020000
RRULE:FREQ=YEARLY;UNTIL=20370329T010000Z;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19961027T030000
RRULE:FREQ=YEARLY;UNTIL=20361026T010000Z;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20250902T080000
DTEND;TZID=Europe/Berlin:20250902T082500
DTSTAMP:20250623T084923Z
UID:ef9bf8e328e1a6cb7fdb63ffd1d54bca1eee4ce7
CREATED:20250623T084924Z
LAST-MODIFIED:20250623T084924Z
SUMMARY:Testtermin
CLASS:PRIVATE
STATUS:CONFIRMED
TRANSP:OPAQUE
X-EVOLUTION-CALDAV-ETAG:5187bb99623969b62f0b1315360a1fc3
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:Testtermin!
TRIGGER:-PT30M
X-EVOLUTION-ALARM-UID:29782990752b1a015cc0e5f7ec94981433ab20e4
END:VALARM
END:VEVENT
END:VCALENDAR

Die Default-Zeitzone in Evolution ist: System, also "Europa/Berlin" Zweite Zone: keine

Kann sein, dass ich mal mit Termindauer "gespielt" habe, glaube ich aber nicht.

Ja, "Format der Region" ist zweifach eingestellt, sowohl bei "Zeit und Datum" als auch bei "Nur das Datum". Nie berührt.

Danke für Tipps!

Es könnte sein, dass meine BIOS-Batterie langsam schwächelt, aber dann würde ich es doch in der oben dargestellten Abfrage gesehen haben? Und es wäre nicht so statisch Winter-/Sommerzeit abhängig, der Fehler, meine ich?

Ich habe es wohl, wenn das angeboten wurde, als Snap installiert, ist jedenfalls "3.52.3-0ubuntu1".

Ich denke nicht, dass du Evolution als Snap installiert hast. Es wäre neu für mich, dass es so etwas gibt. Aus der Versionsbeschreibung vermute ich eher, dass du eine "deb" Installation durchgeführt hast.

Zur ".ics" Datei: Die sieht absolut ok aus. Ich habe die Datei in einen CalDAV Kalender (t-online) importiert und es wird der Termin von 08:00 - 08:25 angezeigt. Das gleiche Ergebnis beim gmail und dem lokalen Kalender.

Bei den lokalen Kalendern steht bei den DTSTART/DTEND Tokens als "TZID" zwar nicht der "Europe/Berlin" Eintrag sondern "/freeassociation.sourceforge.net/Europe/Berlin", was aber daran liegt, dass die lokale TZ Definition auf diesem lokalen System aus dem "sourceforge.net" Bereich mit korrekter Definition stammt. Unterschiedlich sind bei allen Importen der "X-EVOLUTION-CALDAV-ETAG" Eintrag. Dies ist aber normal, da dieser Eintrag zur Synchronisation mit dem jeweiligen Server System herangezogen wird (werden kann).

Einträge ohne TZID (wie DTSTAMP) sind auch korrekt mit dem "Z" am Ende für die UTC-0 Normierung.

Somit ist die gelistete .ics Datei absolut ok und fehlerfrei. Wenn du diesen Eintrag in deinen Kalender importierst, solltest du den Termin von 08:00-08:25 sehen können. Dies habe ich auch mit einem Testsystem, bei dem Evolution der Version "3.52.3-0ubuntu1" über "deb" installiert ist, nachvollziehen können.

Da du auch die Konfiguration der Evolution GUI validiert hast und die Einträge in Ordnung sind, sollte der "Testtermin" auch korrekt dargestellt werden.

Danke!

Ja, also der Import des og. Testtermins funktioniert bei mir auch fehlerfrei.

Der Fehler taucht ja auch immer nur während der Winterzeit, also derzeit, auf. Gebe ich die Termine per iPad ein, werden sie auch am Linux-PC in Evolution korrekt angezeigt.

Nur die Eingabe mittels Evolution am LinuxPC muss ich immer um eine Stunde später angeben, damit der Termin korrekt eingetragen wird. Es ist zum Mäusemelken!!

Nur die Eingabe mittels Evolution am LinuxPC muss ich immer um eine Stunde später angeben, damit der Termin korrekt eingetragen wird.

Was du oder der CalDAV Server falsch macht, kann ich leider nicht erahnen. Ich habe in einem Testsystem mit der über 2 Jahre veralten deb Version Einträge für einen CalDAV Server hier noch einmal ausprobiert und alles hat funktioniert. Als CalDAV Server habe ich den T-Online Kalender verwendet.

Die einzige Vermutung, die ich habe ist, dass du die Zeitzone beim Erfassen nicht korrekt einträgst oder der CalDAV Server deines Providers mit diesen Informationen nicht das macht, was du erwartest.

Um dies zu prüfen kann man im ersten Schritt die beiden durch iPad und GUI erfassten Kalendereinträge als ".ics" Datei exportieren und sich deren Inhalt anschauen. Eventuell lassen sich hier bereits Differenzen feststellen.

In einem weiteren Schritt kann man auch die CalDAV Kommunikation über Evolution leicht debuggen, um festzustellen, welche Daten tatsächlich an deinen CalDAV Server gesendet werden und ob diese auch korrekt beantwortet werden.

Danke! 😊

shiro schrieb:

Nur die Eingabe mittels Evolution am LinuxPC muss ich immer um eine Stunde später angeben, damit der Termin korrekt eingetragen wird.

Was du oder der CalDAV Server falsch macht, kann ich leider nicht erahnen. Ich habe in einem Testsystem mit der über 2 Jahre veralten deb Version Einträge für einen CalDAV Server hier noch einmal ausprobiert und alles hat funktioniert. Als CalDAV Server habe ich den T-Online Kalender verwendet.

Die einzige Vermutung, die ich habe ist, dass du die Zeitzone beim Erfassen nicht korrekt einträgst oder der CalDAV Server deines Providers mit diesen Informationen nicht das macht, was du erwartest.

Überall, sowohl in Evolution-Client als auch im Linux-System steht alles auf Europa/Berlin. Also in Evolution ist aktiviert: "Zeitzone des Systems verwenden (Europa/Berlin)". Im System steht noch dabei, dass "NTP Sync" aktiviert ist.

Der CalDAV-Server meines Providers reagiert aber doch auf iOS-CalDAV-Dateien nachweislich anders als auf Evolution (Client)-CalDAV-Dateien. Er reagiert korrekt, trage ich per Web-Oberfläche des Providers im Kalender ein. Einzig Evolution "kennt keine Winterzeit" und trägt während des Winter alles um eine Stunde früher ein.

In meinem ganzen "System" aus Web-Terminkalender-Oberfläche des Providers, einem iOS- und einem iPadOS-Gerät und einem Linux-PC reagiert nur Evolution-Client seltsam. Leider ist es der wichtigste Kalender.

Um dies zu prüfen kann man im ersten Schritt die beiden durch iPad und GUI erfassten Kalendereinträge als ".ics" Datei exportieren und sich deren Inhalt anschauen. Eventuell lassen sich hier bereits Differenzen feststellen.

Ich würde hier eher Differenzen zwischen allen Zugängen (Web, iOS, iPadOS) und Evolution erwarten?

Wie gesagt, tritt das Problem nur während der Winterzeit auf. Derzeit also nicht. Ich habe jetzt mal einen Apriltermin per drag'n drop in den März geworfen: Er wird eine Stunde früher eingetragen.

In einem weiteren Schritt kann man auch die CalDAV Kommunikation über Evolution leicht debuggen, um festzustellen, welche Daten tatsächlich an deinen CalDAV Server gesendet werden und ob diese auch korrekt beantwortet werden.

Auch wenn das jetzt nicht zur Problemlösung beiträgt:

... Einzig Evolution "kennt keine Winterzeit" und trägt während des Winter alles um eine Stunde früher ein.

Ich würde das anders formulieren. Da ist ständig die Sommerzeit aktiv.
Die Winterzeit ist eigentlich die normale Zeit, also die Zeit bei der Mittags um 12:00h in der Mitte der Zeitzone die Sonne am höchsten steht.

Aber das Fehlerbild verwirrt mich. So wie du es bisher beschrieben hast, betrifft das nur Evolution. Da das ein Profi-Programm ist, kann ich mir nicht vorstellen, dass da ein Fehler passiert ist. Man benötigt eigentlich nur die Funktionen localtime() und gmtime() die die Zeiten System weit richtig angeben. Aber wie das jetzt zwischen den Geräten kommuniziert wird, davon habe ich keine Ahnung.

Drag&Drop funktioniert mit Version 3.58.2 als Flatpak von Sommer- zu Winterzeit fehlerfrei.

Ich habe es wohl, wenn das angeboten wurde, als Snap installiert, ist jedenfalls "3.52.3-0ubuntu1".

Das Paket, das du installiert zu haben scheinst, sieht aus wie das .deb Paket vom 28.06.2024. Im Moment aktuell ist "evolution 3.60.0 (by Flathub.org)" vom 13.03.2026 und da hat es sehr wohl etliche Anpassungen gegeben. Die neuste Version ist 3.60.1 vom 10.04.2026 hat aber noch nicht das "stable" Attribut. Es wäre daher eventuell überlegenswert, auf die aktuelle 3.60.0 Version z.B. via flatpak zugehen, da hierdurch keine Interferenzen mit der .deb Version entstehen. Aber das solltest du entscheiden.

Um dies zu prüfen kann man im ersten Schritt die beiden durch iPad und GUI erfassten Kalendereinträge als ".ics" Datei exportieren und sich deren Inhalt anschauen. Eventuell lassen sich hier bereits Differenzen feststellen.

Ich würde hier eher Differenzen zwischen allen Zugängen (Web, iOS, iPadOS) und Evolution erwarten?

Die Daten des CalDAV Servers sollten ja stets gleich sein. Da das Format genormt ist, sollten (bis auf die Reihenfolge der Einträge) keine gravierenden Änderungen zu erwarten sein. Werden dennoch Unterschiede gefunden, so sind diese interessant und könnten einen Einblick in das von dir festgestellte Problem geben.

In einem weiteren Schritt kann man auch die CalDAV Kommunikation über Evolution leicht debuggen, um festzustellen, welche Daten tatsächlich an deinen CalDAV Server gesendet werden und ob diese auch korrekt beantwortet werden.

Zu diesem Zitat hast du keine Bemerkung geschrieben. Ich vermute aber, dass du auch gern ein Debugging der Schnittstelle durchführen möchtest. Dies ist online möglich bei einer Flatpak Installation (z.B. unter 3.60.0) mittels

$ # Erzeuge Transfer-Verzeichnis für flatpak
$ mkdir ~/evo
$ flatpak document-export --app=org.gnome.Evolution -r -w ~/evo
/run/user/1000/doc/642ba040/evo
$ flatpak run --command=sh org.gnome.Evolution
[📦 org.gnome.Evolution ~]$ CALDAV_DEBUG=1 /app/libexec/evolution-calendar-factory -w >& logfile &
[1] 18
[📦 org.gnome.Evolution ~]$ evolution &
[2] 24
[📦 org.gnome.Evolution ~]$ # Erstelle und Verschiebe Eintrag über Sommerzeit-Grenze (vom 13.04.26 zum 17.03.26)
[📦 org.gnome.Evolution ~]$ ls -sh log*
80K logfile
[📦 org.gnome.Evolution ~]$ evolution --force-shutdown
[📦 org.gnome.Evolution ~]$ 
[1]+  Fertig                     CALDAV_DEBUG=1 /app/libexec/evolution-calendar-factory -w >&logfile1
[📦 org.gnome.Evolution ~]$ cp -p logfile /run/user/1000/doc/642ba040/evo
[📦 org.gnome.Evolution ~]$ exit
exit
$ ls evo
logfile
$ 

Bei einer .deb Installation müsste dies (ungetestet) lauten:

$ cd ~/Downloads
$ evolution --force-shutdown
$ CALDAV_DEBUG=1 evolution-calendar-factory -w >& logfile &
$ evolution &
$ # nun Aktionen mit dem CalDAV Kalender durchführen
$ evolution --force-shutdown
$ 

Die Datei "logfile" enthält die vereinfachte "soap" Kommunikation. Man kann zwar auch detaillierter debuggen, doch sollte dies zunächst nicht erforderlich sein.

Du kannst dann sehr schön sehen, wie der Kalender synchronisiert wird (über "REPORT" und "getetag"), bevor es los geht. Schau, ob bei der Kommunikation Fehler festgestellt werden, da sich etliche CalDAV Server ja nicht an die RFC Norm halten. Daten, die an den Server gesendet werden zeigen in der 1. Spalte ein ">". Daten, die vom Server empfangen werden ein "<" Zeichen.

Das Anlegen eines Termin-Eintrags erfolgt mit dem "PUT" Befehl dem die RFC 5545 Definitionen folgen. Beim Verschieben des erstellten Termins werden die Daten mit aktualisierten "DTSTART" und "DTEND" gesendet. Bevor du den logfile veröffentlichst, verändere bitte die Authentisierungs-Einträge (z.B. "Authorization: Bearer ..." bei OAUTH2 oder die Passwort Information bei schwacher Authentisierung von z.B. "Authorization: Basic"). Eventuell erkennst du aber sofort aus dem Logfile, wo die Probleme liegen.

Ich hatte im obigen Beispiel den Termin am aktuellen Tag erzeugt und dann auf den 16.03.2026 (Winterzeit) verschoben. Die angezeigten Zeiten waren aber stets korrekt weshalb sich dein Problem nicht reproduzieren ließ. Ich hoffe, durch den Debug Mitschnitt zu sehen, ob die Zeiten bei dir in irgendeiner Form von dem Verhalten der Benutzer abweicht, bei denen alles korrekt funktioniert.

Zu den beobachteten Effekten kann es kommen, wenn die Zeit auf dem lokalen Rechner (auf dem Evolution läuft) nicht richtig tickt. Was zeigt denn:

timedatectl 

Die Ausgabe von timedatectl hatte der TS bereits im mit der Eröffnung des Themas im ersten Post geliefert.

Für mich sieht das auch richtig aus. War während der Winter(Normal)zeit, also dann wenn die Probleme auftreten.