Menu

#10 RRULE.UNTIL requires UTC time

future
closed
None
2015-08-18
2015-08-15
No

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

1 Attachments

Discussion

  • Michael Angstadt

    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:

    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.

    However, if it's part of any other component:

    RFC 5445, p. 41:

    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 addition, the deprecated specs, RFC 2445, state that UNTIL must always be in UTC:

    RFC 2445 p.42

    If specified as a date-time value, then it MUST be specified in an UTC time format.

    I committed a fix. Please let me know your thoughts.

    Thank you,
    Mike

     
  • Peter Menhart

    Peter Menhart - 2015-08-17

    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:

    DTSTART;TZID=America/New_York:20150908T203000
    RRULE;TZID=America/New_York:FREQ=DAILY;UNTIL=20150909T203000

    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

    RRULE:FREQ=DAILY;UNTIL=20150910T003000Z

    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:

    RRULE:FREQ=DAILY;UNTIL=20150910T035959Z

    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

     
  • Michael Angstadt

    Thanks for the explanation, Peter. I'm glad it works now!

     
  • Michael Angstadt

    • status: open --> closed
     
  • Michael Angstadt

    Closed the ticket.

     

Log in to post a comment.

MongoDB Logo MongoDB