Scenario
There is a centralized calendar in SharePoint which contains various events across offices around the world. Each office may have it's own time zone. The user experience is that they should be able to search and filter these events thus involving a search scope and customized search results.
The SharePoint servers are in the Eastern time zone and have that setting. All events are being stored in EST. (UPDATE: All events are stored in SharePoint as UTC. The date/time is then converted to the timezone of the user viewing the event item based on their regional settings at the site collection level - at least in MOSS 2007. Since our service account is EST, we retrieve all times in EST from the web service). A web service queries the events calendar list and produces search results accordingly using custom metadata properties mapped to the crawled web service properties via BDC/BCS.
Problem
If all meetings and events are stored as EST, and the web service just returns the start and end times, those times will all be EST. However, since there are offices all around the world, that means there are users all around the world. So the problem is that the search results should display the time of event based on the user who is viewing the events.
Workaround/Solution/Hack
Because I was locked into search results already I had to go that route. This could have been easily resolved if I had some sort of MVC application running and use javascript to dynamically calculate the event time client-side.
So instead, I had to modify the the web service to produce the start and end times for each time zone in which there was an office. For example, DisplayStartTimeEST would store the Eastern time, and DisplayStartTimePST would store the Pacific time. I then added all of these new fields to the BDC/BCS definition and crawled the content source. I mapped new metadata properties to the underlying crawled properties of the web service.
In the search results XSLT, I essentially show every time zone within a <div> whose (style) classes match the time zone. The style classes are all set to be hidden.
The style example is shown here:
The HTML in the XSLT looks like the following:
So the only thing left to do is figure out the user's time zone (based on their machine setting) and then show the proper time zone value. To get the time zone, I used the jsTimeZoneDetect code available here. Then I all I had to do is add a javascript function to show the proper <div> based on the time zone that was determined. I placed this code on the search results page via a Content Editor Web Part (since it was SharePoint 2007):
Results
With my machine set to Eastern Time, I saw the search results in EST:
Conclusion
My solution is a hack but it works!!! So to wrap up, the solution basically is to bring back all time zones in the search results and then only show the correct one based on the user's time zone setting. Using a different display mechanism other than search results and calculating the time zone on the fly would be a more elegant solution but I had to work with what I was given.
There is a centralized calendar in SharePoint which contains various events across offices around the world. Each office may have it's own time zone. The user experience is that they should be able to search and filter these events thus involving a search scope and customized search results.
The SharePoint servers are in the Eastern time zone and have that setting. All events are being stored in EST. (UPDATE: All events are stored in SharePoint as UTC. The date/time is then converted to the timezone of the user viewing the event item based on their regional settings at the site collection level - at least in MOSS 2007. Since our service account is EST, we retrieve all times in EST from the web service). A web service queries the events calendar list and produces search results accordingly using custom metadata properties mapped to the crawled web service properties via BDC/BCS.
Problem
If all meetings and events are stored as EST, and the web service just returns the start and end times, those times will all be EST. However, since there are offices all around the world, that means there are users all around the world. So the problem is that the search results should display the time of event based on the user who is viewing the events.
Workaround/Solution/Hack
Because I was locked into search results already I had to go that route. This could have been easily resolved if I had some sort of MVC application running and use javascript to dynamically calculate the event time client-side.
So instead, I had to modify the the web service to produce the start and end times for each time zone in which there was an office. For example, DisplayStartTimeEST would store the Eastern time, and DisplayStartTimePST would store the Pacific time. I then added all of these new fields to the BDC/BCS definition and crawled the content source. I mapped new metadata properties to the underlying crawled properties of the web service.
In the search results XSLT, I essentially show every time zone within a <div> whose (style) classes match the time zone. The style classes are all set to be hidden.
The style example is shown here:
So the only thing left to do is figure out the user's time zone (based on their machine setting) and then show the proper time zone value. To get the time zone, I used the jsTimeZoneDetect code available here. Then I all I had to do is add a javascript function to show the proper <div> based on the time zone that was determined. I placed this code on the search results page via a Content Editor Web Part (since it was SharePoint 2007):
With my machine set to Eastern Time, I saw the search results in EST:
I then changed my time zone to Pacific:
When I refresh the search results, I now see the event time in PST:
Conclusion
My solution is a hack but it works!!! So to wrap up, the solution basically is to bring back all time zones in the search results and then only show the correct one based on the user's time zone setting. Using a different display mechanism other than search results and calculating the time zone on the fly would be a more elegant solution but I had to work with what I was given.
Lots people are very week in cdoing for date/time settings.i m totally confused when whn i get the work like you described.but your article is very usefull for me.
ReplyDeleteI always emailed this weblog post page to all my friends,
ReplyDeletefor the reason that if like to read it afterward my contacts will too.