When events are published with local timezone info, some clients (Outlook, Google Calendar) do not interpret "until" time of recurring events correctly. Turns out that rfc5545 specification of UNTIL requires: "If specified as a DATE-TIME value, then it MUST be specified in a UTC time format." (see http://tools.ietf.org/html/rfc5545#section-3.3.10 for all the complex details).
I fixed rendering of "until" in RecurrencePropertyScribe to always use UTC, see attached patch. Clients are interpreting my use cases properly now.
Please review and decide whether this fix is generally useful.
Thanks
Peter
Hi Peter,
Thanks for pointing this out. The way I read the specs is that it depends on what component the RRULE property is part of. The sentence that you quoted only holds true if the RRULE property is part of a VTIMEZONE component.
RFC 5445, p. 41:
However, if it's part of any other component:
RFC 5445, p. 41:
In addition, the deprecated specs, RFC 2445, state that UNTIL must always be in UTC:
RFC 2445 p.42
I committed a fix. Please let me know your thoughts.
Thank you,
Mike
Hi Mike,
Your fix works nicely for me, thanks!
Let me illustrate the problem for other users.
We'll schedule an event to occur twice: Sept 8 and Sept 9, at 8:30PM EST. When the VEVENT is set with local timezone:
then Google Calendar correctly shows two occurrences, but Outlook or Thunderbird will miss the second one (displays only occurrence of Sept 8). Those clients seems to interpret the UNTIL value ignoring the timezone. The value has to be published in UTC
for all clients to interpret the value correctly. (Note: I am showing output of Biweekly here, not the programming interface.)
For many use cases, time portion of UNTIL is not relevat. Can it be set to 23:59 of the last day? Sure, if the value is converted to UTC. For our example, we can use 11:59PM EST, and Biweekly has to publish 3:59AM UTC next day (4 hours behind UTC in summer); i.e. the output is:
Risk of lost occurrence applies for timezones to the west of GMT. For timezones ahead of GMT, there is an opposite problem: a chance of extra ocurrence past the intended end.
Luckily, Biweekly users do not have to worry about all these details, as the library handles the conversion to UTC under the hood now!
Have a nice day
Peter
Thanks for the explanation, Peter. I'm glad it works now!
Closed the ticket.