Ankündigung

Einklappen
Keine Ankündigung bisher.

Bugs in Serienterminen iCal & Co.

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Bugs in Serienterminen iCal & Co.

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

    Beispieleintrag der ics Datei:

    Code:
    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


    #2
    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.

    Kommentar


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

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

      Kommentar


        #4
        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.
        Zuletzt geändert von wvhn; 10.09.2020, 16:08.

        Kommentar


          #5
          Muss ich erst testen. Ich melde mich.

          Kommentar


            #6
            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
            Code:
            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

            Kommentar


              #7
              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):

              Code:
              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:

              Code:
              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
              Zuletzt geändert von Sipple; 14.09.2020, 20:17.

              Kommentar


                #8
                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

                Kommentar


                  #9
                  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:

                  Code:
                  BEGIN:VEVENT
                  CLASS:PUBLIC
                  DTSTAMP:20200910T110608Z
                  DTEND;VALUE=DATE:19450924
                  DTSTAMP:20200910T110608Z
                  DTSTART;VALUE=DATE:19450923
                  RRULE:FREQ=YEARLY;BYMONTHDAY=24;BYMONTH=9
                  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

                  Kommentar


                    #10
                    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

                    Kommentar


                      #11
                      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

                      Kommentar


                        #12
                        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.

                        Kommentar


                          #13
                          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

                          Kommentar


                            #14
                            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.

                            Code:
                            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:

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

                            44.png


                            Jetzt das Jahr mal auf 1946, also:

                            Code:
                            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

                            Kommentar

                            Lädt...
                            X