Broker::processMessageReply

[strokyl]

Currently, Broker::processMessageReply ignore exceptions that have a recurrent id in a different time-zone than the DTSTART of the master event. This cause issue in Sabre when a attendee update his partstat on an instance using a client that use UTC for recurrent id.

[strokyl]

I have done a PR : https://github.com/fruux/sabre-vobject/pull/360

[evert]

I'm reasonably certain that RECURRENCE-ID must be in the same timezone as the DTSTART it's referencing, but I've been wrong before.

I'm going to do some digging.

[evert]

I read the relevant section in RFC5545, and I do think that the correct interpretation is that RECURRENCE-ID must be an exact match:

   Value Type:  The default value type is DATE-TIME.  The value type can
      be set to a DATE value type.  This property MUST have the same
      value type as the "DTSTART" property contained within the
      recurring component.  Furthermore, this property MUST be specified
      as a date with local time if and only if the "DTSTART" property
      contained within the recurring component is specified as a date
      with local time.

While it doesn't explicitly say that TZID must be identical, I don't see, logically speaking at least, why that would ever make sense. Thoughts?

[strokyl]

Furthermore, this property MUST be specified as a date with local time if and only if the "DTSTART" property contained within the recurring component is specified as a date with local time.

This sentence let me think, that if dtstart is not in local time, who can choose what you want as TZID for the recurrent id. Moreover I think even if this case does not make sense, it's better to support it or if Sabre don't support it the server should reject recurrent with exception having a recurrent id with different TZID from dtstart. In our frontend for sack of simplicity all recurrent-id are computed in UTC (after thought that probably bad but I think if we did it, other will do it too). So it's better to have a resilient back-end about that.

[gharlan]

Google calendar always replies with UTC recurrence-id. Even for existing exception events that were sent to google with a different time zone in dtstart and recurrence-id.

So I think this should be handled in iTip\Broker.

[phil-davis]

The currently proposed solution is in PR #652