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 (7)
  1. Jeremy Esposito says:

    Would it be possible to provide some data/time query syntax examples?

    Thanks!

    Jeremy

  2. Knut Brandrud says:

    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.

  3. Anurag says:

    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

  4. Knut Brandrud says:

    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.

  5. Thanks Kunt for quick reply.

    But problem over here is we are populating full date in a DB using search web service. Do we need to update the code to handle date time zone or is there any configuration in SP that will make FAST to store date according to local server time zone

  6. Thanks Kunt for quick reply.

    But problem over here is we are populating full date in a DB using search web service. Do we need to update the code to handle date time zone or is there any configuration in SP that will make FAST to store date according to local server time zone

  7. Knut Brandrud says:

    Dates will always be stored in the index as UTC. It is up to the search front-end to convert to local time if desired. If I understand you right, the UTC date indexed is correct, but you want the 'write' date/time presented according to local time.

    The date presented in the UI (example above, date without time component) is adjusted for local time. However, if you just want to present the content of the 'write' managed property, you will need to convert the UTC date/time to local time in your front-end.

Comments are closed.

Skip to main content