I was playing around with Search Based solutions in SharePoint 2010, inspired by the presentation of Scot Hillier (here). I really see a lot of potential for Search-Based solutions. Why bother with custom code, mucking around with timerjobs and such, trying to scrape together information from lists, sites and sitecollections, if you have all that information at your disposal in the search database?
So, to try my hand at a Search-Based solution, I thought I’d make a My Tasks webpart. A lot of customers would like to have a webpart that shows all tasks assigned to them, without them having to look through every site they are a member of.
Building the webpart wasn’t so difficult, but when I deployed the webpart, I was puzzled by the result. The webpart showed the three tasks I expected. What I didn’t expect were the deadlines (due date field).
Please note the deadline of the first task: 20-09-2011 (dutch date format: dd-mm-yyyy)
I was sure I entered the due date 21-09-2011, right??
Let me check the task…
What the …!?
Why is search (KeywordQuery) returning an incorrect date?
And this turned out to be the case for all date fields.
So, I decided to debug and investigate the search results up close, especially the date fields.
Hmmm…. Every datetime value I received in the results was 2 hours ‘earlier’…
A colleague of mine suggested reading this blog post about a similar problem with the SharePoint client object model. And then I finally realized SharePoint stores its datetime fields in UTC time. If you don’t look at the data from SharePoint through the UI (the UI corrects datetime values according to local time), you need to correct the datetime fields with the UTC offset you have locally.
Maybe this is all too familiar for some of you, but if you’re confronted with this problem for the first time, you’re kinda flabbergasted… 
So, using the DateTimeOffset, I modified the DateTime fields in de search results and…
TADA!
I’m a happy camper again. 
