More forgiving DTSTART behavior when using only date for UNTIL

[grimmdude]

First, thank you for your work on this library 🙏

When UNTIL is defined simply as a date, like 20230331, and you pass a UTC datetime to the second argument of the RRULE constructor you get the following error:

new RRule('RRULE:FREQ=WEEKLY;WKST=SU;UNTIL=20230331;INTERVAL=2;BYDAY=TH', date_create());

Invalid UNTIL property: 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.

I understand if this technically abides by the RFC spec, however internally the library seems to cast the value of UNTIL into a UTC datetime anyway.

> $rrule = (new RRule('RRULE:FREQ=WEEKLY;WKST=SU;UNTIL=20230331;INTERVAL=2;BYDAY=TH'))->getRule()
= [
    "DTSTART" => null,
    "FREQ" => "WEEKLY",
    "UNTIL" => DateTime @1680220800 {#3854
      date: 2023-03-31 00:00:00.0 UTC (+00:00),
    },
    "COUNT" => null,
    "INTERVAL" => "2",
    "BYSECOND" => null,
    "BYMINUTE" => null,
    "BYHOUR" => null,
    "BYDAY" => "TH",
    "BYMONTHDAY" => null,
    "BYYEARDAY" => null,
    "BYWEEKNO" => null,
    "BYMONTH" => null,
    "BYSETPOS" => null,
    "WKST" => "SU",
  ]

Would it be acceptable for the library to be a little more forgiving in this case and allow a UTC datetime to be used as the value for DTSTART?

[rlanvin]

First, thank you for your work on this library 🙏

You are welcome!

Would it be acceptable for the library to be a little more forgiving in this case and allow a UTC datetime to be used as the value for DTSTART?

This is a good question. You are correct, this behaviour comes from the RFC 5545 section 3.3.10 and in fact the error message is a copy/paste of the specification. In theory of course the library could be more forgiving, but in practice I'm not in favour of relaxing this behaviour, because this would lead to confusion and different results in some circumstances. For example, in your code snippet, you are giving a DTSTART with time component (i.e. a datetime). But your UNTIL doesn't have one (i.e. it's a date only). If the library were to accept this, this would create an ambiguity with 3 possible interpretation:

1. should the time component of the UNTIL be 00:00:00 and DTSTART whatever it is?
2. or should the time component of the UNTIL be assumed to be the same as the one for DTSTART?
3. or should the time component of DTSTART be ignored altogether because you didn't pass one in the UNTIL?

Each scenario has issues:

• Scenario 1 will mean that there won't be an occurrence on the date of the UNTIL (because the rule will stop at midnight on that day, but the occurrence will be at whatever time was in DTSTART, so past the UNTIL date).
• Scenario 2 modifies the rule, so generating a string version from the object will actually lead to a different rule (one with a time component in UNTIL).
• Scenario 3 also modifies the rule, but this time DTSTART will be different

More importantly, there is no way to know what is the intent of the programmer and to decide which option to choose. That's why the RFC explicitly rejects this case. The human needs to be more precise, so that the computation can be accurate and reproducible between implementations.

As a workaround in your example, could you simply use date_create()->format('Y-m-d') to truncate the unnecessary time component that you don't need?

I hope that makes sense.

[grimmdude]

Thanks for your reply, @rlanvin.

For context, Google calendar API seems to occasionally provide only a date value for UNTIL for recurring events that start at a specific time (the example I posted above came directly from Google). Although not explicitly provided, the DTSTART value in this case is 2023-01-05 07:00:00Z as defined by the event's start time.

Perhaps I'm misunderstanding something, or perhaps this is a bug on Google's side. For this situation though, it seems I'll need to modify the UNTIL value to use a 00:00:00 datetime prior to instantiating the RRULE class in order to avoid the exception. Since the library seems to already do this internally, that was what prompted me to ask the question.

Essentially your first scenario is what I was envisioning. I probably have a myopic view of the issue, but to me this seems like a reasonable solution. I def respect wanting to keep the behavior as tight to the RFC spec as possible though. Maybe triggering an E_USER_WARNING instead in this case would be suitable since it's still possible to proceed.

In any case, thank you for taking the time to discuss.