Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RRULE.UNTIL requires UTC time #10

Closed
mangstadt opened this issue Aug 15, 2015 · 5 comments
Closed

RRULE.UNTIL requires UTC time #10

mangstadt opened this issue Aug 15, 2015 · 5 comments

Comments

@mangstadt
Copy link
Owner

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
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link
Owner Author

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

Original comment by: mangstadt

@mangstadt
Copy link
Owner Author

  • status: open --> closed

Original comment by: mangstadt

@mangstadt
Copy link
Owner Author

Closed the ticket.

Original comment by: mangstadt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant