mangstadt / biweekly

biweekly is an iCalendar library written in Java.
BSD 2-Clause "Simplified" License
323 stars 44 forks source link

RRULE.UNTIL requires UTC time #10

Closed mangstadt closed 8 years ago

mangstadt commented 9 years ago

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

Reported by: pmenhart

Original Ticket: biweekly/tickets/10

mangstadt commented 9 years ago

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

Original comment by: mangstadt

mangstadt commented 9 years ago

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

Original comment by: pmenhart

mangstadt commented 9 years ago

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

Original comment by: mangstadt

mangstadt commented 9 years ago

Original comment by: mangstadt

mangstadt commented 9 years ago

Closed the ticket.

Original comment by: mangstadt