UNTIL value stored in RRULE for event with DTSTART of type datetime is treated as a local time when it should be treated as UTC

[twoodruff01]

First time contributing to open source and I'm no expert on rfc5545 and all things ical, but I've been trying to use RRULEs for recurring events in an application and may have found a bug. I may be misreading the RFC too.

RFC has this to say:

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.

The relevant part is 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.

The issue I'm facing is that I'm storing zoned datetime dtstarts for my events, and so I'm following the spec and also storing their respective RRULE UNTILs in UTC but when I generate events from them usually the last event is missing because ical assumes the stored UNTIL value is in local datetime and not UTC.

[twoodruff01]

This is one of the test cases given in the RFC:

Every 3 hours from 9:00 AM to 5:00 PM on a specific day:

DTSTART;TZID=America/New_York:19970902T090000
RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z

==> (September 2, 1997 EDT) 09:00,12:00,15:00

It seems like UNTIL is being stored as a local/naive time in UNTIL and they're just appending a Z on the end and calling it UTC even though it's not? 19970902T170000Z

Since America/New_York is UTC-4 I would have expected the stored value to be 19970902T210000Z

[twoodruff01]

Checked libical and their test suite has this case:

# Every 3 hours from 9:00 AM to 5:00 PM on a specific day
RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z
DTSTART:19970902T090000
INSTANCES:19970902T090000,19970902T120000,19970902T150000

Quite similar to the one above, but the DTSTART value is not explicitly zoned. So it seems they're treating the whole test case as just UTC and not using America/New_York timezone anywhere.

Link to test file: https://github.com/libical/libical/blob/4.0/src/test/icalrecur_test.txt

[twoodruff01]

Ok have spent a little while looking at a fix for this and I think it would be a bit of work and potentially break existing functionality so won't be raising a PR. Also don't want to raise a PR with AI slop. Below is the code I wrote to isolate the problem before I started investigating this more. I would have expected it to produce 4 datetimes but it only produces 3:

    tz = "Australia/Melbourne"

    {:ok, dtstart_naive} = NaiveDateTime.from_iso8601("2026-01-01T10:00:00")
    dtstart = DateTime.from_naive!(dtstart_naive, tz)

    dtend_date = ~D[2026-01-22]

    until =
      ICal.as_valid_datetime(dtend_date, NaiveDateTime.to_time(dtstart), tz)
      |> DateTime.shift_zone!("Etc/UTC")
      |> Calendar.strftime("%Y%m%dT%H%M%SZ")

    rrule = ICal.Recurrence.from_ics("RRULE:FREQ=WEEKLY;UNTIL=#{until}")

    %ICal.Event{
      dtstart: dtstart,
      dtend: DateTime.add(dtstart, 1, :hour),
      rrule: rrule
    }
    |> ICal.Recurrence.stream(end_date: dtend_date)
    |> Enum.to_list()

result:

[#DateTime<2026-01-01 10:00:00+11:00 AEDT Australia/Melbourne>,
 #DateTime<2026-01-08 10:00:00+11:00 AEDT Australia/Melbourne>,
 #DateTime<2026-01-15 10:00:00+11:00 AEDT Australia/Melbourne>]

Would have expected that to include #DateTime<2026-01-22 10:00:00+11:00 AEDT Australia/Melbourne>

[giriss]

Wow! We had the same issues at the same time 😅
Rest assured @twoodruff01 I've already made a PR for this.
I think now that you've raised this issue, I am not alone, my PR will hold more ground.
See my PR #52

[aseigo]

It seems like UNTIL is being stored as a local/naive time in UNTIL and they're just appending a Z on the end and calling it UTC even though it's not? 19970902T170000Z

From the RFC:

" 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."

So for RRULEs, the DTSTART defines the timezone used for the rest of the rule.

However, the point does remain that floating local time is still being parsed as a DateTime which defaults to having a UTC timezone. I'll move that part of the conversation over to the PR #52

[aseigo]

Could @giriss and @twoodruff01 try the code in the master branch with your apps? If it resolves the issues, I will prepare a release, otherwise we can iterate on whatever is left to fix up. Thanks in advance!