(this is a copy of a post that is not available anymore)
DateRangesOverlap Value Type
I don’t know if any back-end developers have run into this same issue when working with the SPQuery to pull expanded recurrence date, but from here, not all DateRangesOverlap Value types work the way they should. And they’re cryptically-documented, where mentioned at all. The basics are that you can return dates that « overlap » a given scenario. The overlapping varies depending on scenario, as follows:
<Year />
This is supposed to get all events within:
(a) Today’s year (if no CalendarDate is passed), or
(b) the date passed in QueryOptions as CalendarDate.
Actually, it returns all dates from [Today] into the future. It ignores:
(a) the CalendarDate, and
(b) the end of the current year
<Month />
Performs consistently as expected, with the exception that its definition of « month » is more of a « month view. » A month view consists of all of the weeks which contain days in that month. In other words, the month view for May 2012 begins on April 29, 2012, because May 1 is on a Tuesday and the « month view » consists of full weeks. Likewise, the May 2012 month view ends on June 5, 2012. This means that pulling all of the dates for May 2012 will return all events for April 29 – June 5.
However, even though April 29 is the beginning of the May month view, when passed as the CalendarDate, it will return the April month view. See below for how this affects date calculations based on pulling data for a given month.
<Week />
Performs exactly like <Month />, but only returns the corresponding week for:
(a) Today, or
(b) CalendarDate
<Today />
Returns just the events for Today.
<Now />
Contrary to most documentation, <Now /> doesn’t « work » but rather defaults to the same results as <Year />.
In fact, <Year /> is the default. If you leave off the entire WHERE clause, but include the RecurrenceDate and fRecurrence fields and the QueryOptions (CalendarDate will be ignored), you get the same results as <Year />.
CalendarDate
In QueryOptions, if the CalendarDate is set, it needs the date to be a string in the format:
yyyy-mm-ddThh:mm:ssZ
In most cases, setting the CalendarDatewhen needed to the real date on which you want to base your range will work just fine, as long as you set the time in the Z-notation to noon. The reason for the noontime setting is to make allowance for all-day events within the given range. These tend to get messed up when viewing is based on a midnight or early morning time. Basing the range on noon alleviates the issue. (At least it does for US time zones; I confess that I haven’t tested them all.)