Date and time in FAST Search Server queries and results

Handling date and time can be tricky on a query interface. If you create an end-user search interface, you may want to adapt to the user's timezone. You may decide to determine the user's timezone based on the locale, which makes sense in certain cases, but not always. You could use IP address, etc., but this may not work well in many corporate environments. My office is in Oslo, but the gateway out of the corporate network happens to be in Ireland. Hence, many applications tend to believe that I'm in Ireland.

If you look at how the SharePoint search web parts works, you will see that they are timezone aware. In the following search result, there are two test documents with different date/time in the write managed property. The first date is just showing the content of the write managed property. In the index, all datetime properties are represented as UTC. The second date is added by the web part, and is adjusted to my locale. I'm located in Oslo, which is one hour ahead of Greenwich.

In FAST Search for SharePoint, you can choose between two different query languages. The Keyword Syntax is the default query language in SharePoint. When using this language, you should be aware that all dates are adjusted according to the locale of the user. When using the Query OM, this is determined by the culture property. If you use the FAST Query Language (FQL), all dates should be specified in UTC syntax, and the search client should perform the necessary mapping. This is in most cases the preferred approach for search driven applications.

If you use query refinement, there are some other concerns. The default statistical binning in FAST Search Server will not give you datetime bins with reasonable date boundaries. What you typically want instead, is buckets such as 'today', 'yesterday', 'last week', 'last month', etc. You can do that as well, but then you need to create the (non-overlapping) bins per query in the client, based on the time when the user performs the query. Then you can combine these to provide possibly overlapping bins such as  'yesterday' and 'last week'. This is described in more detail in Query Refinement. If you want to adapt the bins to the user's time zone, you must specify the bins on date and hour boundaries to reflect change of day in the user's timezone, but specified in UTC.

See also part 2, which discusses datetime query syntax.

Comments

• Anonymous
  June 07, 2011
  Would it be possible to provide some data/time query syntax examples? Thanks! Jeremy

• Anonymous
  June 13, 2011
  Added some query syntax examples in a recent blog, blogs.msdn.com/.../date-and-time-in-fast-search-server-queries-and-results-part-2.aspx.

• Anonymous
  September 25, 2011
  Is this possible the result for write manage property comming in FAST query be same as that in list. If yes how? I have one report in library with Modified date 9/24/2011 3:20 AM but fast is giving 2011-09-24T10:20:11Z in Write manage property and I want 2011-09-24 03:20:000 this format and if it is 9/24/2011 3:20 PM it should come like 2011-09-24 15:20:000. Server is in Pecific time zone

• Anonymous
  September 25, 2011
  Note that the full date/time presented in the result is UTC (GMT). This is the way the query results web part works. I'm not aware of any customization options for this, except extending the web part with custom code or creating your own web part or search front-end. Note that the actual 'Date' info for the results is adjusted for your locale, but as indicated it does not provide the time info.

• Anonymous
  September 26, 2011
  The comment has been removed

• Anonymous
  September 26, 2011
  The comment has been removed

• Anonymous
  September 26, 2011
  The comment has been removed