Bugs in Serienterminen iCal & Co.

[Sipple]

Kann es sein, dass in calender.list ein Bug bei periodischen Terminen steckt?

Beispieleintrag der ics Datei:

BEGIN:VEVENT
CLASS:PUBLIC
DTEND;VALUE=DATE:19450924
DTSTAMP:20200910T110608Z
DTSTART;VALUE=DATE:19450924
RRULE:FREQ=YEARLY;BYMONTHDAY=24;BYMONTH=9
SEQUENCE:0
SUMMARY;LANGUAGE=de:Max Mustermann hat Geburtstag
TRANSP:TRANSPARENT
UID:040000008200E00074C5B7101A82E0080000000050DA84B06D87D601000000000000000
0100000002BA59293D2FF8D45AF1EA89E5D2E430F
X-MICROSOFT-CDO-BUSYSTATUS:FREE
END:VEVENT

Also ein ganztägiges Ereignis, das jährlich wiederholt wird. Siehe RRULE:FREQ=YEARLY;BYMONTHDAY=24;BYMONTH=9.
Er zeigt aber in calender.list den 25. an, rechnet also bei allen events einen Tag drauf. Bei allen.

Kalender.png

[wvhn]

Als Max Mustermann hätte ich auch was dagegen, dass mein richtiger Geburtstag im Müllkalender steht

Siehst Du den Fehler nur bei Serienterminen, oder generell bei ganztägigen Terminen? Mit „bei allen“ meinst Du alle Elemente der Serie?

In der calendar.js ist die Darstellung der Termine tatsächlich etwas unglücklich gelöst. Allerdings sehe ich noch keinen Grund für die Addition eines Tages.

[Sipple]

Momentan nur bei Serienterminen und da bei allen Terminen einer Serie und allen Serien.

Und das ist kein Müllkalender, sondern ne zweite ics

[wvhn]

Auch bei Serienterminen, die nicht ganztägig sind? Sorry fürs penetrante Nachfragen. Ich brauche die Info fürs Suchen im Code.

zudem wäre interessant zu wissen, ob das auch bei Serien passiert, die nach 1970 starten. Vor 1970 sind Daten nämlich negativ und das kann ggfls. übersehen worden sein.

[Sipple]

Muss ich erst testen. Ich melde mich.

[wvhn]

Sipple , wenn ich Serientermine aus iCloud lade, stimmt die Darstellung. Offenbar legt iOS das ganztägige Ereignis vom 23.9. 0:00 Uhr bis 24.9. 0:00 Uhr an und damit geht der Calender Service korrekt um. Woher bekommst Du Deine ics-Datei? Ich denke wir müssen dann einmal sehen, was bei ics als Standard definiert ist und ob wir bei einzelnen Services Korrekturen vornehmen können / müssen.

Das Parsing von ics läuft übrigens bei allen Services im selben Modul ab: iCal.php

Folgender ics-Code führt zur richtigen Darstellung des Geburtstags: 23.9.2020

BEGIN:VCALENDAR
X-EXPANDED:True
X-MASTER-DTSTART:20190922T160000
X-MASTER-RRULE:FREQ=YEARLY
BEGIN:VEVENT
DTSTAMP:20200911T233041Z
CREATED:20191028T155430Z
DTSTAMP:20200706T202310Z
LAST-MODIFIED:20200706T202302Z
SEQUENCE:0
SUMMARY:Geb. Max Mustermann (1957)
UID:45F2...geheim
URL;VALUE=URI:
TRANSP:OPAQUE
DTSTART;VALUE=DATE:20200923
DTEND;VALUE=DATE:20200924
RECURRENCE-ID:20200923T070000Z
END:VEVENT
END:VCALENDAR

Gruß
Wolfram

[Sipple]

Guten Morgen

Leider habe ich grad nicht ganz so viel Zeit zum Testen, aber mal so viel:

Ich habe zwei .ics Dateien. Die eine ist ein Müllkalender vom Abfallentsorgungsunternehmen. Da sieht ein Eintrag so aus (Location Zeile habe ich raus genommen, ist eh irrelevant):

DTSTART;VALUE=DATE:20200915
DTEND;VALUE=DATE:20200916
TRANSP:TRANSPARENT
UID:1599645460649-45@abfuhrtermine.awp-paf.de
DTSTAMP:20200909T115740Z
DESCRIPTION;LANGUAGE=de:Bitte stellen Sie die Behälter bis 6:00 Uhr zur Abholung bereit.
SUMMARY;LANGUAGE=de:Biotonne
PRIORITY:9
CLASS:PUBLIC
URL:www.awp-paf.de
STATUS:CONFIRMED
END:VEVENT

Das sind ganztägige Einträge, wobei Start- und Ende NICHT der selbe Tag ist. Siehe oben, 15.09. Start und 16.09. Ende. Es sind auch Einzeltermine, also nicht wiederkehrend, z.B. wöchentlich oder jährlich an einem festen Datum. Es sind logischerweise auch keine Uhrzeiten enthalten.
Das kommt richtig raus, exakt so, wie es imho sinnvoll ist.

Biotonne.png

EIN Eintrag ohne Uhrzeit mit richtigem Datum. Das erwähne ich deshalb so genau, weil die Welt sich irgendwie nicht einig zu sein scheint, wie man einen ganzen Tag denn nun kodiert. Manche Systeme machen da zweimal das selbe Datum für Start und Ende, andere machen das so wie oben. Beim Dekodieren machen manche Tools daraus dann auch gerne mal ZWEI Tage.

Die zweite Datei ist ein Kalender der nur Geburts- und Jahrestage enthält. Den habe ich z.B. mit dem Google Kalender (erster Versuch) und mit Outlook 365 (zweiter Versuch) erstellt und jeweils als .ics exportiert.

Einträge wie z.B. dieser hier:

BEGIN:VEVENT
CLASS:PUBLIC
DTEND;VALUE=DATE:19450925
DTSTAMP:20200910T110608Z
DTSTART;VALUE=DATE:19450924
RRULE:FREQ=YEARLY;BYMONTHDAY=24;BYMONTH=9
SEQUENCE:0
SUMMARY;LANGUAGE=de:Max Mustermann hat Geburtstag
TRANSP:TRANSPARENT
UID:040000008200E00074C5B7101A82E0080000000050DA84B06D87D601000000000000000
0100000002BA59293D2FF8D45AF1EA89E5D2E430F
X-MICROSOFT-CDO-BUSYSTATUS:FREE
END:VEVENT

Start am 24.09.1945 und Ende am 25.09.1945 (nach der Logik vom Abfallkalender). Keine Uhrzeiten enthalten (abgesehen von DTSTAMP). Dafür gibt es eine RRULE, die auf jährlich am 24.09. steht. Sieht für mich absolut plausibel aus.

Was dabei rauskommt ist das:

Geburtstag.png

Also völliger Quatsch. Der eigentliche Tag, der 24. kommt gar nicht vor und er setzt den Termin auf die ZWEI folgenden Tage und fügt eine Uhrzeit von 0:00 am ersten Tag bis 1:00 am zweiten Tag ein.

Was ich probiert habe:

1. DTEND und DTSTART auf das selbe Datum, den 24.09.1945.

Geburtstag2.png

Etwas besser, aber immer noch ein Tag zu spät und immer noch die überflüssige Uhrzeit drin.

2. Die RRULE rausgenommen, DTSTART auf den 24.09.2020 und DTEND auf den 25.09.2020 (also Kodierung wie im Abfallkalender ohne wiederkehrende jährliche Termine).

Geburtstag3.png

Passt. Aber dann muss ich jedes Jahr den Termin manuell neu setzen.

3. Wie 2., aber zusätzlich noch spaßeshalber DTSTART und DTEND beide auf den 24.09.2020 gesetzt, weil ich was geahnt habe.

Geburtstag4.png

Tag stimmt, die überflüssige Uhrzeit ist wieder da und natürlich muss ich auch hier im nächsten Jahr alles neu machen.

4. DTSTART auf den 24.09.2020, DTEND auf den 25.09.2020 und die RRULE:FREQ=YEARLY;BYMONTHDAY=24;BYMONTH=9.

Geburtstag5.png

Richtiges Startdatum, dann aber auch noch ein ZWEITER Termin einen Tag später und keine Uhrzeit.

Schlussfolgerung meinerseits:

1. DTSTART muss das korrekte Datum des ganztägigen Termins sein, DTEND das Datum des NÄCHSTEN Tages. Keine Uhrzeiten.
2. RRULE bewirkt momentan bei mir, dass immer mindestens ein Tag zum eigentlichen Datum hinzuaddiert wird und unter Umständen eine völlig wirre Uhrzeit, wie oben erwähnt, z.B. 0:00 Start bis 1:00 Am nächsten Tag.

Verwirrt? Ich auch. Ist ein wenig wie "Wenn du die Haare geschnitten bekommst, häng deine Kleider auf den unteren Haken"

Wolfram, iCloud kodiert die RRULE also komplett anders, noch nicht mal innerhalb eines VEVENT. Wie sieht das dann bei mehr als einem jährlichen Termin aus?

Gruß, Martin

[wvhn]

Super systematisch aufbereitet. Vielen Dank! Ich muss mir das wohl im Detail ansehen, was sicherlich einige Zeit dauert.

Wenn jemand hier Erfahrung hat, bin ich für jede Hilfe dankbar!

Gruß
Wolfram

[Sipple]

wvhn

Ich habe die Lösung - prinzipiell. Dein iCloud Beispiel und Recherche im Netz haben mich drauf gebracht, dass man bei einem jährlich wiederkehrenden Termin an einem bestimmten Datum DTSTART (und gegebenenfalls DTEND) um einen Tag vorverlegen muss. Will man also den 24.9. jährlich haben, muss das so aussehen:

BEGIN:VEVENT
CLASS:PUBLIC
DTSTAMP:20200910T110608Z
[COLOR=#e74c3c][B]DTEND;VALUE=DATE:19450924[/B][/COLOR]
DTSTAMP:20200910T110608Z
[B][COLOR=#e74c3c]DTSTART;VALUE=DATE:19450923[/COLOR][/B]
[COLOR=#e74c3c][B]RRULE:FREQ=YEARLY;BYMONTHDAY=24;BYMONTH=9[/B][/COLOR]
SEQUENCE:0
SUMMARY;LANGUAGE=de:Max Mustermann hat Geburtstag
TRANSP:TRANSPARENT
UID:040000008200E00074C5B7101A82E0080000000050DA84 B06D87D601000000000000000
0100000002BA59293D2FF8D45AF1EA89E5D2E430F
X-MICROSOFT-CDO-BUSYSTATUS:FREE
END:VEVENT

So hat es auch ein RRULE Generator im Netz ausgeworfen.
Eine Erklärung, WARUM das so sein muss, habe ich noch nicht gefunden und warum Outlook und Google das falsch ausgeworfen haben auch nicht. Wer also "schuld" ist, kann ich nicht sagen. Zum Glück musste ich meine Geburtstags-ics-Datei nur einmal ändern. Ging recht schnell, sind ja keine >100 Einträge.

Die Frage ist jetzt, ob es dafür eine plausible Erklärung gibt (ganztägige, NICHT wiederholende Ereignisse sind ja auch nicht um einen Tag vorverlegt) und ob einem diese Erkenntnis dann hilft.

Wichtiger ist wohl eher die Frage, ob das nur mich betrifft, dann lass alles so.
Wenn es aber mehrere betrifft, je nachdem, was man für ein Tool verwendet um die .ics Datei zu erzeugen, müsste man überlegen, wie man in diesem Fall vorgeht. Den Code in smartVISU anpassen (Aufgrund welcher Information? Dem Header? PRODID? Aufwand/Nutzen?) oder einen Workaround beschreiben, was auf einen manuellen Eingriff in betroffene .ics Dateien hinausläuft.

Gruß, Martin

[Sipple]

Ah, jetzt verschoben. Sehr schön.

Also hiermit noch einmal der Aufruf an alle, die calender.list im Zusammenhang mit *.ics Dateien verwenden.

Es geht um ganztägige, jährlich wiederkehrende Ereignisse, wie den typischen Geburtstag (eventuell auch andere Ereignisse betroffen).
Wichtig sind die oben rot markierten Zeilen eines VEVENTs.

1. Welche Quelle habt ihr für die *.ics Datei benutzt? Google Calender, Outlook, Thunderbird, Apple, irgendwas anderes?
2. Wie sieht der Eintrag dann aus? Erzeugt die Quelle das dann mit einem DTSTART, das einen Tag VOR dem eigentlichen Termin gesetzt ist und DTEND mit dem eigentlichen Datum? Wie sieht die RRULE aus?
3. Wird das Ereignis dann in calender.list richtig angezeigt oder gibt es die von mir beschriebenen Effekte, z.B. um einen Tag verschoben und zwei Tage lang?

Danke schon mal

Martin

[wvhn]

Sipple, in meinem Beispiel hatte ich einen existierenden Serientermin aus meinem iCloud-Kalender genommen, der zufällig auf dem 23.9. liegt, also einen Tag früher als Deiner. Der Serientermin wird korrekt angezeigt.

Mein Verdacht geht in Richtung der RRULE-Auswertung. Mich würde interessieren, was passiert, wenn man die RRULE weglässt. Im iCloud-Kalender gibt es diese nicht. Dort heißt sie X-Master_RRULE und wird offenbar von der iCal.php garnicht erkannt.

Kannst Du mal in einer Kopie Deiner ics-Datei versuchen, was passiert, wenn man die RRULE löscht? Da in SV eh nur die Termine weniger Wochen angezeigt werden, könnte ich die Auswertung der RRULE als Workaround einfach abklemmen oder auf DAILY, WEEKLY beschränken.

Gruß
Wolfram

[Sipple]

Hi Wolfram. Das habe ich schon oben im Post #7 unter Punkt 2 gemacht.
Dann klappt das natürlich, weil es ja nichts anderes ist wie einer der Einträge des Abfallkalenders. Nur bekomme ich den Termin dann nächstes Jahr natürlich nicht mehr und muss alls wieder von vorne auf 2021 setzen. Dasselbe dann Jahr für Jahr.
Da ist es mir lieber wir lassen alles wie es ist und ich gebe EINMAL Start und Ende einfach einen Tag früher ein. Habe ich ja schon gemacht und es klappt mit diesem Workaround soweit wunderbar.

[wvhn]

Stimmt. Das Weglassen von RRULE hast Du ja schon getestet. Sorry.

Ich bin aber der Meinung, dass man eine ics-Datei mit den üblichen Programmen erstellen und sie in der SV verarbeiten können muss, ohne vorher manuell noch fehlerhafte Daten eingeben zu müssen. Deshalb möchte ich den Fehler auf jeden Fall finden und beseitigen. Nach dem nächsten Update bekommst Du dann alle Termine einen Tag zu früh angezeigt

Wenn Du etwas Zeit zum Testen hast, könntest Du einmal die BYMONTH und BYMONTHDAY Einträge in der RRULE löschen. YEARLY allein sollte eigentlich reichen. Wenn der Bug dann verschwindet, wissen wir, wo der Fehler steckt und ich kann die (recht umfangreichen) Routinen unter die Lupe nehmen und korrigieren.

Gruß
Wolfram

[Sipple]

Hab's grad getestet. Also YEARLY allein reicht ansich schon, wie zu erwarten war, aber ich muss weiterhin DTSTART und DTEND um einen Tag vorverlegen.

Aber jetzt wird's schrill (ich füge jetzt nur noch die entscheidenden Zeilen ein). Die eigentlich logische Variante mit dem Jahr 1945, Start auf den 24. und Ende auf dem 25.

DTSTART;VALUE=DATE:19450924
DTEND;VALUE=DATE:19450925
RRULE:FREQ=YEARLY

Ergebnis:

45.png

Also wie gehabt. Komplett falsch.

Geburtsjahr auf 1944 gelegt, Start und Ende unverändert:

DTSTART;VALUE=DATE:19440924
DTEND;VALUE=DATE:19440925
RRULE:FREQ=YEARLY

Ergebnis:

44.png


Jetzt das Jahr mal auf 1946, also:

DTSTART;VALUE=DATE:19460924
DTEND;VALUE=DATE:19460925
RRULE:FREQ=YEARLY

46.png

Also selbes Ergebnis. Das JAHR hat schon einen Einfluss! Das kapier ich nun wirklich nicht. Wenn 1970 was bewirken würde, könnte ich mir noch was zusammenreimen, aber 1945??? Und um 1970 hab ich auch mal gespielt. Keine Änderung. Die einzige Lösung bleibt weiterhin Start und Ende einen Tag vorzuverlegen. Dann ist das Jahr und die RRULE augenscheinlich egal.

Hier mal ein Screenshot eines RRULE Generators aus dem Netz. Die entscheidenden Punkte markiert:

RRULE.png


Dadurch bin ich drauf gekommen DTSTART mal einen Tag vorzuverlegen. Aber warum? Ist das so gewollt? Für mich sinnfrei - aber funktioniert.

Gruß, Martin

[wvhn]

Sipple ich habe den (extern bezogenen) ICal ICS Parser im Develop Branch auf die aktuelle Version v2.2.2 aktualisiert. In meinem Testumfeld behebt das ein paar Probleme, u.a. auch die Verschiebung um einen Tag bei den Serienterminen.

Die Bibliothek habe ich zusätzlich auf smartvisu-newstuff gestellt. Man kann den aktuellen Ordner ./lib/calendar/ICal in ICal_old umbenennen und den Ordner ICal mit den neuen Dateien anlegen. Das ermöglicht dann auch ein schnelles Zurückwechseln, wenn etwas nicht passt.
Wenn das Update die Fehler behebt, müsste man halt seine eigenen Workarounds zurücknehmen.

Für Tests und Rückmeldungen wäre ich dankbar. Ohne Rückmeldungen landet das Update unverändert im nächsten Release.

Gruß
Wolfram