3

In WSS 3.0, recurring events have IDs for each specific recurrence, as well as the series item. For example, I might have a series item with ID=3, and it runs weekly on Wednesday. Then, the April 27th instance of this event is ID=32.1.3.

However, when one of our clients sent out an email that was intending to link to this event, her hyperlink was to ID=3.0.2011-04-27T19:00:00Z. This caused an unknown error and so the specified ID did not work.

No matter what I try in accessing that event, I cannot get that string, I always get ID=32.1.3. But the client (who is otherwise unfamiliar with SharePoint) is just copy-pasting the URL as it shows up in the browser, which means there had to be some way of getting that other ID initially, and it must have been valid.

Why are there two different formats of IDs? What do they mean? And how do I know when I should be using which one for valid URLs?

Improve this question

1 Answer 1

Reset to default
3

Recurring events in SharePoint are very very complex. This post from Stack Overflow should help - https://stackoverflow.com/questions/2811756/update-item-has-recurrence-in-sharepoint

Basically the format of a instance of a recurring event is

ID=<ID>.0.0.<START DATE OF INSTANCE IN UTC>

But Date is in modified ISO 8601 format with a Z on the end - this is supposed to signify Z aka GMT/UTC but thats not always the case. All Day Events violate this rule as the start instance is NOT in UTC but in eh local time zone, i.e. 00:00:00.

The confusion starts when you modify or delete an instance (and I believe this is what happened in your case) in that case an Event Exception is entered which is a new record that refers back to the modified instance.

In your case

ID=32.1.3 means record #32 is a modified (1) version of recurrence defined in ID #3

So likely that URL was valid when it was sent, but the event instance was since modified.

If you check the All Events view of your calendar and add the ID field in all should become clear.

Improve this answer
2
  • Ooh, I see. So, basically, until it gets modified, it'll be the timestamp of the recurrence, but once it gets modified, it then gets treated as its own ID (32, in this case), and it consequently uses a notice of the root (3) instead of the timestamp. This is enlightening. Makes it a pain to try and figure how best to avoid links breaking, but definitely a step forward. Thank you much!
    – Grace Note ♦
    Commented May 6, 2011 at 14:56
  • Exactly - you would have to do something very fancy to stop links breaking, I would be interested to know if you manage to come up with anything.
    – Ryan
    Commented May 6, 2011 at 17:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.