Fixed
Project:
Smart Date
Version:
4.3.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
13 Nov 2025 at 16:07 UTC
Updated:
3 Jul 2026 at 14:56 UTC
Jump to comment: Most recent
iCalendar validator confirms this:
Invalid RRULE value (invalid 'UNTIL' value) near line # 11
Reference: 3.8.5.3. Recurrence Rule $ical_link[] = '' . str_replace('-', '', $options['repeats']);
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:
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:
Comments
Comment #2
robmaurizi commentedComment #4
mark_fullmerAgreed: this is really a formatting issue arising from
smart_date/modules/smart_date_recur/src/Entity/SmartDateRule.phpI 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-24T235959Correct:
RRULE:FREQ=WEEKLY;UNTIL=20260424T235959Comment #5
mark_fullmerTransferring from addtocal_augment to smart_date issue queue.
Comment #6
jmester13 commentedFor those who land here I made a patch here https://www.drupal.org/project/addtocal_augment/issues/3418383 that maybe helpful to you.
Comment #7
mandclu commentedComment #8
mandclu commentedFor reference, here is the section of RFC 5545 relevant to UNTIL:
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.
Comment #10
mandclu commentedHere'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.
Comment #12
mandclu commentedThe fix has been merged into the 4.3.x branch of Smart Date.