Produits Entr'ouvert » Passerelle

J'ai l'impression que c'est juste un non respect de la spec (https://www.rfc-editor.org/rfc/inline-errata/rfc5545.html#inline-4414) :

      The UNTIL rule part defines a DATE or DATE-TIME value that bounds
      the recurrence rule in an inclusive manner.  If the value
      specified by UNTIL is synchronized with the specified recurrence,
      this DATE or DATE-TIME becomes the last instance of the
      recurrence.  The value of the UNTIL rule part MUST have the same
      value type as the "DTSTART" property.  Furthermore, if the
      "DTSTART" property is specified as a date with local time, then
      the UNTIL rule part MUST also be specified as a date with local
      time.  If the "DTSTART" property is specified as a date with UTC
      time or a date with local time and time zone reference, then the
      UNTIL rule part MUST be specified as a date with UTC time.  In the
      case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL
      rule part MUST always be specified as a date with UTC time.  If
      specified as a DATE-TIME value, then it MUST be specified in a UTC
      time format.  If not present, and the COUNT rule part is also not
      present, the "RRULE" is considered to repeat forever.

Donc ici le 2100-01-01 ne devrait pas non plus fonctionner si DTSTART contient un date-time et pas un date, en me référant à :

• https://formulaires-www.entrouvert.com/backoffice/workflows/25/status/1/items/3/
• et https://formulaires-www.entrouvert.com/backoffice/workflows/25/status/8/items/1/

Je ne sais pas s'il existe un validateur de format iCal en python mais ce serait pratique d'avoir ça dans le connecteur avant de pousser du contenu vers le serveur caldav.

Benjamin Dauvergne a écrit :

J'ai l'impression que c'est juste un non respect de la spec (https://www.rfc-editor.org/rfc/inline-errata/rfc5545.html#inline-4414) :

Ah oui, bien vu, c'est certainement une bonne piste !

Je ne sais pas s'il existe un validateur de format iCal en python mais ce serait pratique d'avoir ça dans le connecteur avant de pousser du contenu vers le serveur caldav.

J'avoue que j’espérais un peu qu'avec caldav basé sur icalendar ça soit le cas.. Dans la doc de icalendar on trouve "It’s outside the scope of this library to implement logic for parsing and modifying RFC 5545, instead we depend on another library for that". Mais visiblement l'autre bilbliothèque n'aide pas vraiment pour le problème dont il est question :

>>> import datetime, icalendar
>>> event = icalendar.Event()
>>> event.add('dtstart', datetime.datetime.fromisoformat('2020-02-20T20:00Z'))
>>> event.add('dtend', datetime.datetime.fromisoformat('2020-02-21T20:00Z'))
>>> event.add('summary', 'test')
>>> event.add('uid', '1234567890abcdef')
>>> event.add('rrule', {'FREQ': 'DAILY', 'UNTIL': datetime.date(2020, 5, 1)})
>>> print(event.to_ical().decode('utf-8'))
BEGIN:VEVENT
SUMMARY:test
DTSTART:20200220T200000Z
DTEND:20200221T200000Z
UID:1234567890abcdef
RRULE:FREQ=DAILY;UNTIL=20200501
END:VEVENT

Il génère un truc invalide sans broncher, et j'ai pas trouvé de méthode check/verify ou autre qui permettrait de garantir que la RFC 5545 est respectée :/

Du coup dans la PR proposée les vérifications/conversions sont faites "à la main" pour garantir la cohérence entre DTSTART et RRULE/UNTIL