Closed mangstadt closed 8 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
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
Thanks for the explanation, Peter. I'm glad it works now!
Original comment by: mangstadt
Original comment by: mangstadt
Closed the ticket.
Original comment by: mangstadt
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