Fix(calendar): all-day events in iCalendar format (RFC 5545)

[Marc-Andrieu]

Description

Summary

Now, day(s)-long events are also displayed as such, on the event module's calendar, on Google Calendar and on iOS iCalendar, AND the start and end dates are correct.

Sources

RFC 5545, 3.6.1. Event Component:

The "DTSTART" property for a "VEVENT" specifies the inclusive start of the event. For recurring events, it also specifies the very first instance in the recurrence set. The "DTEND" property for a "VEVENT" calendar component specifies the non-inclusive end of the event. For cases where a "VEVENT" calendar component specifies a "DTSTART" property with a DATE value type but no "DTEND" nor "DURATION" property, the event's duration is taken to be one day.

Issues/PR dependencies

Issues to be resolved

Fixes #331

Changes Made

• [x] All-day events are recognized as such on the 3 calendars clients. That was pretty easy
• [x] There is no gap, shift in days, missing days or extra days. That was not so easy, I had to find the explication in the RFC to be sure of what they did.
• [x] Classical events are still OK.
• [x] Resilient to daylight saving time: no matter if your event is scheduled in November or in May, the 3 calendars display the same thing.

Classification

Type of Change

• [x] 🐛 Bug fix (non-breaking change which fixes an issue)
• [ ] ✨ New feature (non-breaking change which adds functionality)
• [ ] 🔨 Refactor (non-breaking change that neither fixes a bug nor adds a feature)
• [ ] 🔧 Infra CI/CD (changes to configs of workflows)
• [ ] 💥 BREAKING CHANGE (fix or feature that require a new minimal version of the front-end)
• [ ] 😶‍🌫️ No impact for the end-users

Impact & Scope

• [ ] Core functionality changes
• [x] Single module changes
• [ ] Multiple modules changes
• [ ] Database migrations required
• [ ] Other: ...

Testing

• [x] 1. Tested this locally,
  • [x] and importing in my Google Calendar,
  • [x] and asked a iPhone friend to import my local file in iCalendar
• [ ] 2. Added/modified tests that pass the CI (or tested in a downstream fork)
• [ ] 3. Tested in a deployed pre-prod
• [ ] 0. Untestable (exceptionally), will be tested in prod directly

Documentation

• [ ] Updated the docs accordingly :
• [x] " Docstrings
• [ ] # Inline comments
• [ ] No documentation needed