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
Broker::processMessageReply #358
Comments
I have done a PR : https://github.com/fruux/sabre-vobject/pull/360 |
I'm reasonably certain that I'm going to do some digging. |
I read the relevant section in RFC5545, and I do think that the correct interpretation is that RECURRENCE-ID must be an exact match:
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? |
This sentence let me think, that if |
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 |
The currently proposed solution is in PR #652 |
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.
The text was updated successfully, but these errors were encountered: