Date Format Compatibility Issue with Radicale CalDAV Server

[MaxSPG]

Description

I am encountering a date format compatibility issue when using the FullCalendar plugin with the Radicale CalDAV server. The plugin sends dates in the "YYYYMMDDTHHMMSS" format, which Radicale does not seem to accept, leading to a "400 Bad Request" error.

Environment

• FullCalendar Version: v6.1.10
• FullCalendar CalDAV Plugin Version: [the latest version from CDN]
• Radicale Version: v2.1.12
• Browser and Version: Edge v119.0.2151.72
• Server: ubuntu (Cloud)
• Reverse Proxy: NGINX

Steps to Reproduce

1. Configure FullCalendar with the CalDAV plugin to connect to a Radicale CalDAV server.
2. Attempt to fetch events from the server.
3. Observe that the request fails with a "400 Bad Request" error.

Expected Behavior

The FullCalendar CalDAV plugin should format dates in a way that is compatible with common CalDAV servers like Radicale, or it should provide a way to configure the date format.

Actual Behavior

The plugin sends dates in the "YYYYMMDDTHHMMSS" format. Radicale seems to expect a different format, leading to a "400 Bad Request" error.

Additional Information

• The problematic code is in the ICAL.Time.fromJSDate(arg.range.start).toICALString() function call, which formats the dates.
• Radicale's logs indicate a "wrong date format" error.
• I am using the plugin via CDN and cannot modify the source code directly.

Potential Solutions or Suggestions

• Adjusting the plugin to use a more universally accepted date format for CalDAV servers, such as the extended format of ISO 8601.
• Or, providing a configuration option in the plugin to specify the date format.

[escoand]

Congratulations to issue number 1. :-)

Thanks for this good and deeply analyzed explanation. Really a good starting point to work with.

I'm using this plugin together with nextcloud without problems since long time. Wasn't aware of any difficulties. But as long as it doesn't break my installation I'm open for extensions and fixes.

CalDav and iCal from a high level view is not that difficult but anyway used an library to avoid exactly such problem. Sadly not absolutely successful.

According to https://datatracker.ietf.org/doc/html/rfc4791#section-7.3 the current implementation isn't wrong but could be optimized maybe by adding some timezone information:

For the CALDAV:calendar-query REPORT, CalDAV servers MUST rely on the value of the CALDAV:timezone XML element, if specified as part of the request body, to perform the proper conversion of "floating date" and "floating time" values to date with UTC time values. If the CALDAV: timezone XML element is not specified in the request body, CalDAV servers MUST rely on the value of the CALDAV:calendar-timezone property, if defined, or else the CalDAV servers MAY rely on the time zone of their choice.

I'll do some tests in the next days.

[escoand]

Please test the release 1.0.3. This will hopefully fix your issue.

[escoand]

@MaxSPG any updates?

[MaxSPG]

I tested it again with the new version, now the REPORT request does indeed work - no more 400 Bad Request!
The date format looks right as well.

Thanks! 💪