LoxBerry: CalDAV-4-Lox Plugin verfügbar.

[Christian Fenzl]

Kleiner-Gleich 0?

[blacksun]

Dann sind auch Schulferien, wenn kein Termin gefunden wird oder? Wenn kein Eintrag gefunden wurde, dann ist doch fwdays -1

[svethi]

Dann ist aber auch alles andere -1. was soll denn da bei Beginn wohl stehen, wenn es vor 2 Tagen begonnen hat?

[svethi]

Du hättest ja auch einen Tagestermin eingeben können, der bis dann-und-dann täglich wiederholt wird, dann wäre Dein fwdays jeden Tag 0

[blacksun]

Hab ich probiert. Funktioniert mit dem Google Kalender anscheinendn nicht.

vom 11.6.2019 einen Ganztägigen Termin, der sich 10 Tage wiederholt erstellt mit dem Termintext Schulferien
Ergebnis: { "Schulferien": { "Start": 329616000, "End": 329702400, "Summary": "Schulferien", "Description": "", "fwDay": -1, "wkDay": 4 }, "now": 329751254 }
End - Startzeit = 24h, aber now > als End :-) Warum?

Zeit auf dem Loxberry und PC stimmt aber.

[blacksun]

Hallo svethi, habe das Plugin über das aktuelle drüber installiert. Loxberry neugestartet. Wenn ich jetzt 1x meinen Google Kalender abfrage oder auch meinen Outlook.com Kalender kommt im Browser (Firefox) nur ein "{ ". Sonst nix ;-)
Abgefragt habe ich beide Kalender mit diesen Parameter "&fwdays=5&events=Frühschicht"

[svethi]

Ja, habe ich gestern auch schon gemerkt. Kommt durch den ganzen Umbau. Das passiert, wenn nichts gefunden wird. Hätte denn was gefunden werden müssen? Habe gestern aber schon noch was korrigiert und wollte paar Tests laufen lassen. Irgendwann war es dann aber zu spät ;-)

[blacksun]

Okay, und nein es hätte nichts gefunden werden müssen. Kannst nochmal eine aktuellere Version in Github einstellen? Änderungen sind noch vor 2 Tagen. Dann teste ich heute Nacht nochmal!

[svethi]

War gestern nicht mehr soweit um das hochzuladen

[svethi]

So, ich denke, so sollte es gehen ...
Habe auch gleich ein PreRelease davon gemacht. Kannst also über den Plugin-Manager updaten.

[blacksun]

Sehr geil, teste ich gleich mal.

[blacksun]

Habs installiert. Ist diese Ausgabe so gewollt? Abgefragt habe ich mit fwdays=0&events=Frühschicht

{ "Frühschicht": { "Start": -1, "End": -1, "Summary": "", "Description": "", "fwDay": -1, "wkDay": -1 }, "next": [ { "Start": 330134400, "End": 330220800, "Summary": "Schulferien", "Description": " ", "fwDay": 0, "wkDay": 3 }, { "Start": 330213600, "End": 330238800, "Summary": "Geisterschicht", "Description": "", "fwDay": 0, "wkDay": 3 } ] "now": 330218617 }

Ist ja im Prinzip nicht falsch. Es sind tatsächlich ja zwei Termine eingetragen, 1x Schulferien, 1x Geisterschicht, keine Frühschicht.

Jetzt passt bei dieser Abfrage dann auch der ganztätige Termin Schulferien aus der Terminserie vom 11.6-21.6. täglich wiederholen.

Was aber noch ein bißchen blöd ist, ganztägigen Termin von 18.6.-21.6. Schulferien (Datum nur zum Test), dann ist die Rückmeldung so:
{ "Start": 330048000, "End": 330393600, "Summary": "Schulferien", "Description": " ", "fwDay": -1, "wkDay": 2 }

Ist zwar auch nicht falsch, aber fwday -1 soll ja bedeuten keinen Termin gefunden oder? Termin hat aber korrekterweise gestern angefangen fwDay=-1. Wie könnt man sowas dann im Miniserver auswerten? Start und Ende <> -1?

[svethi]

Ja, die Ausgabe ist soweit korrekt. Die Abteilung next ist ein Array mit den Terminen, die in den Abfragezeitraum passen. Das wurde von einigen gewünscht. Ich weiß zwar nicht wie die das im Miniserver auswerten wollen, aber das wären halt die nächsten anstehenden Termine. Ich weiß nur noch nicht ob ich die generell mit ausgebe, oder nur auf gesonderte Anfrage.
Sieh Dir doch einfach mal die anderen Werte an. Da wird Dir auffallen, das wkDay nur Werte von 1-7 annehmen kann. Wenn der auf -1 steht, dann ist kein Termin gefunden worden. Oder start und ende. Wenn der -1 ist, dann ist der 31.12.2008 23:59:59, der wird wohl auch falsch sein, so ist -1 als start und ende auch nichts gefunden. Fwdays ist hier halt nicht zu gebrauchen.

[blacksun]

Servus svethi

das Problem mit der Serie Schultermin ganztägigen Termin Start am 11.06.2019, Termin endet am 21.6.2019 ist noch nicht ganz ausgestanden, oder ich hab einen Denkfehler drin.

Im Outlook wird das so angezeigt



Also sind heute noch Schulferien (Gott sei Danke, das die wieder rum sind :-)

Im ICS steht aber folgendes drin:

BEGIN:VEVENT
DESCRIPTION:\n
RRULE:FREQ=DAILY;UNTIL=20190620T220000Z;INTERVAL=1
UID:040000008200E00074C5B7101A82E00800000000509AB6E92F28D501000000000000000
 0100000007F89D1E56CB7EF4E97230BC4B09E1155
SUMMARY:Schulferien
DTSTART;VALUE=DATE:20190611
DTEND;VALUE=DATE:20190612
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20190621T105624Z
TRANSP:TRANSPARENT
STATUS:CONFIRMED
SEQUENCE:0
LOCATION:
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-BUSYSTATUS:FREE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:TRUE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:1
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
END:VEVENT

Da stimmt doch das UNTIL nicht! 20190621T220000 wäre hier richtig, oder? Somit fehlt bei einer Terminserie mit einem ganztätigen Termin, der sich täglich wiederholt immer der letzte Tag.

[svethi]

Also für die ICS Datei ist der Server verantwortlich, da kann ich nunmal gar nichts machen, aber der Termin ist doch da völlig korrekt eingetragen. Dein angegebenes Datum wäre völlig falsch, da es sich nicht mehr um einen ganztägigen Termin handelt. Die Angabe im ICS ist in UTC. Übersetzt auf CEST ist das 20190621T000000.

[svethi]

Was sagt denn das Plugin? Wird da für heute noch Ferien angezeigt?

[blacksun]

Klar ist der Server der ICS dafür verantwortlich, aber obs völlig korrekt, mhh.

Aha, der Google trägt nur das Datum ein, wenn man einen ganztägigen Termin erstellt, Microsoft trägt Datum incl. Zeit in UTC ein. Man müsste beim Auswerten, wenn DAILY, praktisch noch auf die Zeit dahinter achten, denn 20190620T220000 wäre ja 20190621.

Plugin sagt, das heute keine Ferien mehr sind ;-)

Der Google Kalender trägt es so ein. Das wäre korrekt.

BEGIN:VEVENT
DTSTART;VALUE=DATE:20190611
DTEND;VALUE=DATE:20190612
RRULE:FREQ=DAILY;UNTIL=20190621
DTSTAMP:20190621T114039Z
UID:4g784ud5hjpdr98ib1v8qu90hb@google.com
CREATED:20190621T114003Z
DESCRIPTION:
LAST-MODIFIED:20190621T114003Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Schulferien
TRANSP:TRANSPARENT
END:VEVENT

Outlook-Kalender

BEGIN:VEVENT
DESCRIPTION:\n
RRULE:FREQ=DAILY;UNTIL=20190620T220000Z;INTERVAL=1
UID:040000008200E00074C5B7101A82E00800000000509AB6E92F28D501000000000000000
 0100000007F89D1E56CB7EF4E97230BC4B09E1155
SUMMARY:Schulferien
DTSTART;VALUE=DATE:20190611
DTEND;VALUE=DATE:20190612
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20190621T105624Z
TRANSP:TRANSPARENT
STATUS:CONFIRMED
SEQUENCE:0
LOCATION:
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-BUSYSTATUS:FREE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:TRUE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:1
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
END:VEVENT

[svethi]

Ich versuche gerade herauszufinden wo es hakt. Machen kann ich da wahrscheinlich nicht viel, da ich das komplette Import, Interpretieren, Auswerten etc. Von der Sabre Lib machen lasse. Diese Sabre ist einer der Hauptentwickler für iCal und iCard und gibt vor RFC konform zu sein. Änderungen müssten hier wohl an der Lib gemacht werden. Meine bisherigen Tests zeigen, dass es eventuell ein Problem mit der Lib und der merkwürdigen Angabe vom Windows gibt. Zur Zeit suche ich nach einer Möglichkeit eine Zeitzone für Tagesevents mitzugeben. Ob ich da was finde weiß ich nicht.

[blacksun]

Habs mir schon gedacht, das die Lib was falsches zurück gibt. Evtl. kann man das Verhalten beim Entwickler der Lib "reklamieren"? Müssten ja mehr Leute das Problem haben. Ich weiß auch nicht, ich hab immer das Glück. Das was ich bräuchte funktioniert dann nicht ;-)

[svethi]

Das Problem tritt nur bei dem blöden Exchange und Tagesevents auf. Um das mal zu verdeutlichen. Ein Tagesevent wird mit value=Date deklariert. Der Wert ist hier dann nur der Tag 20190611 dies ist Zeitzonen unabhängig. Bei einem Tagesevent macht es dann auch keinen Sinn UNTIL explizit in UTC anzugeben und diesen mit dem Zeitzonen Delay, da der Termin selbst ja auch in UTC sein könnte. Genau das passiert hier. Die Lib und das habe ich auch so gemacht, rechnet intern mit UTC. Jetzt wird UNTIL so wie angegeben korrekt mit 20.06.2019 22:00:00 UTC interpretiert was hier 21.06.2019 00:00:00 CEST bedeutet und richtig ist. Da aber der Tagesevent keine Zeit beinhaltet wird er beim berechnen mit 21.06.2019 00:00:00 UTC angesetzt und daher kommt die Differenz. Das ist das Problem dabei, denn dem Value=Date kann man auch keine Zeitzone mitgeben, weil es einfach keine hat. Richtigerweise müsste hier in diesem speziellen Fall die Lib erst das Datum mit der lokalen Zeitzone einlesen und danach auf UTC umrechnen.
Ich hab das dort schonmal in die issues geschrieben.

[blacksun]

Guten Morgen,
hättest du den Link für den Sabre Issue für mich. Würd gern mit lesen.

[svethi]

https://github.com/sabre-io/vobject/issues/448

Aber ich bin noch am ausprobieren und so länger ich darüber nachdenke um so mehr bin ich überzeugt, dass der Exchange da Mist macht. Man kann doch kein zeitzonenbehaftetes Datum mit einem zeitzonenfreien Eintrag vergleichen. Value=Date ist nunmal in jeder Zeitzone von 00:00:00 bis 00:00:00 des nächsten Tages und es ist völlig egal in welcher Zeitzone man ist, es ist immer gleich und damit in UTC falsch. Mal angenommen, Es würde hier in Deutschland jetzt korrekt berechnet, so wäre es aber in jeder anderen Zeitzone falsch.

[svethi]

Okay, es ist nicht zu glauben, doch ich habe in das sabre Lib tatsächlich einen Fehler entdeckt. Diesen haben ich weitergereicht und im aktuellen PreRelease temp gefixt. Sollte so dann funktionieren.

[blacksun]

Guten Morgen @svethi,

du bist der Beste! Jetzt funktionierts auch mit ganztags Terminen und Exchange. Kaum zu glauben, das der Fehler noch keinem aufgefallen ist. Ich sage, vielen Dank für die Zeit, die du hier wieder investiert hast.

[svethi]

So Leute,

es gibt ein neues PreRelease. Es hat sich viel geändert. Das Plugin ist fast komplett neu aufgebaut. Ich habe ein weiteres Mal die Lib geändert. Jetzt hoffentlich das letzte Mal. Der Code und auch die Library sind wesentlich schlanker geworden. Grund für den Austausch sind zum Einen die Terminverschiebungen einer Terminserie, sowie immer wieder auftretenden Probleme beim Einlesen der iCal Data gerade von Microsoft Exchange Servern.

Die Unterscheidung zwischen CalDAV und iCal Daten wurde ebenso geändert, damit auch andere Kalenderserver benutzt werden können.

Einige fragten nach der Möglichkeit die nächsten Termine anzeigen lassen. Dies wurde auch umgesetzt.