Hallo Ralf

Vielen Dank für deine Rückmeldung.

Welchen Punkt in der eGroupware Konfiguration meinst du genau?

Ich frage deshalb, weil ich der Meinung bin, dass alles was ich in eGroupware gefunden habe, auf Europe/Zurich gestellt habe und trotzdem tritt bei neuen Terminen das Problem auf.

Ich habe folgende Settings auf Europe/Zurich eingestellt:

• In eGroupware unter ‘Einstellungen’ - ‘Kalender’ habe ich ‘Use Event TZ’ und ‘Europe/Zurich’ getestet.
• Ich habe in eGroupware die Zeitzoneneinstellungen unter ‘Einstellungen’ - ‘Allgemeine Einstellungen’ - ‘Formatierung und allg. Einstellungen’ auf ‘Europe / Zurich’ gesetzt.

Gibt es noch weitere Settings welche ich übersehen habe?

Du schreibst ja selbst, dass nach der Änderung Termine korrekt angelegt werden. Das ändert natürlich nichts an bereits als zwei-tägig angelegten Terminen.

Es ist mir bisher nie gelungen einen Termin in Outlook auf Client A anzulegen und auf Client B herunterzuladen der dann gepasst hat. Es funktioniert nur, wenn ich einen Termin in eGroupware via Website anlege und dann von beiden Clients herunterlade.

Ich habe nun nochmals die zwei oben genannten Einstellungen verifiziert und diese sind auf Zurich/Europe eingestellt. Anbei nochmals die Logs eines neuen Versuches.

PUT

*** 10.0.0.123 2018-08-22T15:59:09+00:00
PUT /egroupware/groupdav.php/thomas/calendar/6d21efc7-81f5-4d14-8c95-f8affc5701c2.ics HTTP/1.1
User-Agent: CalDavSynchronizer/3.2
If-None-Match: *
Content-Type: text/calendar; charset=utf-8
Host: mail.netcult.ch
Content-Length: 909
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ddaysoftware.com//NONSGML DDay.iCal 1.0//EN
BEGIN:VTIMEZONE
TZID:W. Europe Standard Time
BEGIN:STANDARD
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYHOUR=3;BYMINUTE=0;BYMONTH=10
TZNAME:Mitteleuropäische Zeit
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYHOUR=2;BYMINUTE=0;BYMONTH=3
TZNAME:Mitteleuropäische Sommerzeit
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
CLASS:PUBLIC
DESCRIPTION:Hallo Welt\nDies ist ein zweiter Testeintrag mit Zeitzone Europ
 e/Zurich
DTEND;VALUE=DATE:20180820
DTSTAMP:20180822T155909Z
DTSTART;VALUE=DATE:20180819
LOCATION:Remote
PRIORITY:5
SEQUENCE:0
SUMMARY:Testeintrag II
TRANSP:TRANSPARENT
UID:6d21efc7-81f5-4d14-8c95-f8affc5701c2
X-MICROSOFT-CDO-BUSYSTATUS:FREE
END:VEVENT
END:VCALENDAR
HTTP/1.1 201 Created
Date: Wed, 22 Aug 2018 15:59:09 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.6.37
X-Powered-By: PHP/5.6.37
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Dav-Powered-By: EGroupware 17.1.003 CalDAV/CardDAV/GroupDAV server
Schedule-Tag: "597:0"
ETag: "597:0:1534953549"
X-WebDAV-Status: 201 Created
*** PUT /thomas/calendar/6d21efc7-81f5-4d14-8c95-f8affc5701c2.ics --> "201 Created" took 0.123 s

PULL

HTTP/1.1 207 Multi-Status
Date: Wed, 22 Aug 2018 16:00:13 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.6.37
X-Powered-By: PHP/5.6.37
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Dav-Powered-By: EGroupware 17.1.003 CalDAV/CardDAV/GroupDAV server
X-WebDAV-Status: 207 Multi-Status
DAV: 1, 2, access-control, calendar-access, calendar-auto-schedule, calendar-proxy, calendarserver-principal-property-search, calendarserver-private-events, calendar-managed-attachments
Content-Type: text/xml; charset="utf-8"

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:">
 <D:response xmlns:ns0="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/" xmlns:ns2="urn:ietf:params:xml:ns:caldav">
  <D:href>/egroupware/groupdav.php/thomas/calendar/6d21efc7-81f5-4d14-8c95-f8affc5701c2.ics</D:href>
   <D:propstat>
    <D:prop>
     <D:getetag>"597:0:1534953549"</D:getetag>
     <ns2:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//EGroupware//NONSGML EGroupware Calendar 17.1.001//DE
BEGIN:VTIMEZONE
TZID:Europe/Zurich
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;VALUE=DATE:20180818
DTEND;VALUE=DATE:20180820
X-MICROSOFT-CDO-ALLDAYEVENT:TRUE
X-MICROSOFT-CDO-BUSYSTATUS:FREE
SUMMARY:Testeintrag II
DESCRIPTION:Hallo Welt\nDies ist ein zweiter Testeintrag mit Zeitzone
  Europe/Zurich
LOCATION:Remote
PRIORITY:5
TRANSP:TRANSPARENT
UID:6d21efc7-81f5-4d14-8c95-f8affc5701c2
STATUS:CONFIRMED
CREATED:20180822T155909Z
LAST-MODIFIED:20180822T155909Z
DTSTAMP:20180822T160013Z
END:VEVENT
END:VCALENDAR
</ns2:calendar-data>
     <D:displayname>Testeintrag II</D:displayname>
    </D:prop>
   <D:status>HTTP/1.1 200 OK</D:status>
  </D:propstat>
 </D:response>
</D:multistatus>
*** REPORT calendar-multiget /thomas/calendar/ --> "207 Multi-Status" took 0.110 s

Es tritt trotzdem der selbe Fehler auf.

Update: Nun habe ich noch versucht in der eGroupware Datenbank in egw_config die server_timezone von UTC auf Europe/Zurich umzustellen. Auch mit einem neuen Termin tritt das selbe Problem auf. Ich weiss nicht weiter.

Beste Grüsse
Tom

Hallo Ralf

Was Du nicht ändern kannst/sollst sind die Einstellungen des Linux Systems. Die EGroupware Datenbank speichert Ihre Timestamps in der Zeitzone die in egw_config.config_value für config_name=‘timezone’ steht. Wenn Du nach der Installation den Wert änderst, sind deine bis dahin gespeicherten Termine verschoben bzw. bei ganztägigen Terminen einen Tag zu lange.

Siehe initialer Post:

In der timezone in egw_config steht UTC. Ich habe dies auf Europe/Zurich angepasst, ohne dass alle meine Termine verschoben waren. Auch neu angelegte ganztägige Termine haben dann noch das Problem, dass Sie nach dem Pull sich über zwei Tage erstrecken.

Bei mir gibt es keine config_name=“timezone” nur “server_timezone” - du meinst die, oder?
Ist der Wert Europe/Zurich für diesen Configeintrag in der DB valide?

Wenn Du den timezone Wert in der egw_config änderst, musst Du die Datenbank manuell darauf anpassen.

Ist das relevant, wenn ich alle Kalenderinformationen der DB löschen kann und dann mit der korrekten Einstellung neu pushen/pullen kann?

Ich habe dies auf Europe/Zurich angepasst, ohne dass alle meine Termine verschoben waren. Auch neu angelegte ganztägige Termine haben dann noch das Problem, dass Sie nach dem Pull sich über zwei Tage erstrecken.

Was meinst du mit ‘musst du die Datenbank manuell darauf anpassen’?

Dh. im ersten Schritt musst Du rausfinden welche Zeitzone Dein Linux verwendet,

Siehe initialer Post:
Mein CentOS hat folgende Zeitzonen-Einstellungen:
#date
Wed Aug 22 15:50:20 CEST 2018
#ls -l /etc/localtime
lrwxrwxrwx. 1 root root 35 Jul 31 15:50 /etc/localtime -> …/usr/share/zoneinfo/Europe/Zurich

ob Deine Datenbank die gleiche verwendet (SELECT @@global.time_zone, @@session.time_zone;)

MariaDB [(none)]> SELECT @@global.time_zone, @@session.time_zone;
±-------------------±--------------------+
| @@global.time_zone | @@session.time_zone |
±-------------------±--------------------+
| +02:00 | +02:00 |
±-------------------±--------------------+
1 row in set (0.00 sec)

Meines Wissens ist das doch UTC in Europäischer Sommerzeit (+02:00)?

Update: Ich hatte durch meine Tests noch den Eintrag default-time-zone=+02:00 in der /etc/my.cnf

Wenn ich diesen entferne und nochmals die Query absetze, dann steht da:

MariaDB [(none)]> SELECT @@global.time_zone, @@session.time_zone;
±-------------------±--------------------+
| @@global.time_zone | @@session.time_zone |
±-------------------±--------------------+
| SYSTEM | SYSTEM |
±-------------------±--------------------+
1 row in set (0.00 sec)

Es spielt für das Problem offenbar jedoch keine Rolle, da auch bei einem weiteren Test das Problem noch vorhanden ist. Egal ob das SYSTEM oder +02:00 verwendet wird. Auch sind die bestehenden Termine dann nicht verschoben oder ähnliches.

und diese auch in php.ini und egw_config eingetragen ist.

#cat /etc/php.ini | grep -i date.time
date.timezone = Europe/Zurich

Wenn ich dich richtig verstehe, dass ist mein Problem, dass in der egw_config als server_timezone = UTC steht und tz_offset = 2 steht (obwohl dies ja eigentlich Mitteleuropäische Sommerzeit bedeutet).

Wie kriege ich denn dies nun gerade gezogen, ohne das ich Rücksicht auf bestehende Kalenderdaten nehmen muss?

Gruss
Tom

Hallo Ralf

Ich habe die Config nun so wie vorgeschlagen, aber es geht trotzdem nicht

Neu angelegte ganztätige Termine zeigen nach wie vor das selbe Verhalten

MariaDB [(none)]> SELECT @@global.time_zone, @@session.time_zone;
±-------------------±--------------------+
| @@global.time_zone | @@session.time_zone |
±-------------------±--------------------+
| SYSTEM | SYSTEM |
±-------------------±--------------------+
1 row in set (0.00 sec)

MariaDB [egroupware]> select * from egw_config where config_name = ‘server_timezone’;
±-----------±----------------±--------------+
| config_app | config_name | config_value |
±-----------±----------------±--------------+
| phpgwapi | server_timezone | Europe/Zurich |
±-----------±----------------±--------------+
1 row in set (0.00 sec)

Hast du weitere Ideen?

Gruss
Tom

Also ich beende Outlook und damit das CalDAV Plugin auf Client A sowie Client B. Damit müssten die CalDAV Sessions weg sein. Ich habe zusätzlich den Webserver neu gestartet und den MariaDB Server neu gestartet. Es geht nicht.

Hallo Ralf

Du hast ja auch nicht gemacht, was ich gesagt habe: kill die CalDAV Sitzung

Bitte entschuldige - manchmal muss man mit mir wie mit einem Newbie sprechen Die zweiten Instruktionen waren sehr klar Merci beaucoup!

… und Trommelwirbel… der Test war erfolgreich !
… und keiner der bestehenden Termine hat es verschoben !

Danke herzlichst!

Note to myself

Ursache
Als ich das eGroupware RPM installiert habe, war meine /etc/php.ini Datei noch nicht auf die richtige Zeitzone konfiguriert. Irgendwo habe ich gelesen, dass eGroupware bei der Installation des RPMs diese Information aus der php.ini heranzieht um die Zeitzone in der mySQL Datebank (egw_config) zu befüllen.

Einen Hinweis darauf gibt das Install-Log:

#cat /root/egroupware-epl-install.log
PHP Warning:  date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /usr/share/egroupware/setup/setup-cli.php on line 54

Die Zeitzone im Nachgang anpassen

a) In der php.ini

#cat /etc/php.ini | grep -i date.time
date.timezone = Europe/Zurich

b) In der eGroupware DB

use egroupware;
UPDATE egw_config SET config_value='Europe/Zurich' WHERE config_name='server_timezone';

c) Für einen Test die Sitzungen killen (wichtig!):

Admin >> Sitzungen anzeigen >> die entsprechende raussuchen (evtl. User-Agent Spalte einschalten) >> Klick rechts >> Beenden