Repeating events with an end date have an invalid end date in the ICS output.

Steps to reproduce

  1. Create a recurring event that ends on a specific date (ending after N times works as expected)
  2. Click on the iCalendar link
  3. Add the event to MacOS Calendar, and note the event repeats but doesn't end.
  4. Note the RRULE line contains an UNTIL value whose date is malformed (end date contains "-" separators, but should be alphanumeric)

iCalendar validator confirms this:

Invalid RRULE value (invalid 'UNTIL' value) near line # 11
Reference: 3.8.5.3. Recurrence Rule

Different Client Results

  • In Calendar on MacOS, these events repeat indefinitely.
  • In Google Calendar, these events show as not repeating.
  • In Outlook, these events appear to behave as expected.

Proposed resolution

  • Quick fix that works on my local is to str_replace() the hyphens out of the $options['repeats'] string that's pushed onto the ical link:
          $ical_link[] = '' . str_replace('-', '', $options['repeats']);
  • Better option is to update the date format that's stored in $options['repeats']
This module uses Gitlab CI for automated testing of proposed code changes. To contribute code changes, create a merge request. Patch files will not trigger automated testing and are not sufficient for review.

Issue fork smart_date-3557685

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Issue fork addtocal_augment-3557685

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

robmaurizi created an issue. See original summary.

robmaurizi’s picture

robmaurizi commented
Related issues: +#3418383: Google Calendar link issue for recurring item with an end date

robmaurizi opened merge request !31

mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented
Title: Repeating events with an end date have invalid RRULE in ICS » Recurrence Rule for events with an end date are invalid

Better option is to update the date format that's stored in $options['repeats']

Agreed: this is really a formatting issue arising from smart_date/modules/smart_date_recur/src/Entity/SmartDateRule.php

I confirmed through other validation tools (e.g., https://jkbrzt.github.io/rrule/ ) that the RRULE format for a date that repeats UNTIL a certain date should omit the hyphens:

Current, incorrect: RRULE:FREQ=WEEKLY;UNTIL=2026-04-24T235959

Correct: RRULE:FREQ=WEEKLY;UNTIL=20260424T235959

mark_fullmer’s picture

mark_fullmer
he/him
Primary language English
Location Tucson
commented
Project: Add to Calendar Date Augmenter » Smart Date
Version: 1.2.x-dev » 4.2.x-dev

Transferring from addtocal_augment to smart_date issue queue.

jmester13’s picture

jmester13 commented

For those who land here I made a patch here https://www.drupal.org/project/addtocal_augment/issues/3418383 that maybe helpful to you.

mandclu’s picture

mandclu commented
Version: 4.2.x-dev » 4.3.x-dev
mandclu’s picture

mandclu commented

For reference, here is the section of RFC 5545 relevant to UNTIL:

      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.

I don't think we need to address all of that in this issue, but there are some nuances in there (for example, how the UNTIL should match the format and specificity of the DTSTART property) which would be good to capture in or more separate issues.

mandclu opened merge request !218

mandclu’s picture

mandclu commented
Status: Active » Needs review

Here's an MR to implement a fix within Smart Date. I also added test coverage for smart_date_recur while I was at it, which is technically an expansion of scope but hopefully easy enough to ignore for the set of code review and testing.

Note that the changes here do include conditionally adding the end time (i.e. 11:59pm) only if the repeating date is NOT all day. This is also, strictly speaking, an expansion of scope for the issue, but it made sense to me to make the change at the same time since it impacts the code in the same places. It's possible this change will impact the interpretation of existing rules somewhat, for example because Smart Date has force the assumption that the end should be at the end of the specified date, where the new logic does not. I'm not sure if the spec is clear on how the end limit should be interpreted in that regard, but the new behavior follows the spec so I believe we should be content with that.

  • mandclu committed 180768b4 on 4.3.x 
    fix: #3557685 Recurrence Rule for events with an end date are invalid...
mandclu’s picture

mandclu commented
Status: Needs review » Fixed

The fix has been merged into the 4.3.x branch of Smart Date.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.