This issue is driving me nuts.

I am using SharePoint 2010 and FAST search.

In a list there is a column named Upload Date - type: Date only.

Column crawled property ows_uploaddate(Datetime) is mapped to managed property uploaddatedt.

Everything works as expected and in core search results webpart I receive results:


There are +17k items with two different dates (21st and 22nd).

Fun starts when I add the uploaddatedt to Refinement Panel Web Part:

Refiner Web Part

(Don't bother with the look - solution is fully customized and customization isn't part of this problem)

First of all where did the value 2014-08-21T12:00:00Z came from??

Second and more important, how can make Refiner Panel to display this as any other 'normal' (text) property?

My goal is to have exact dates as refinement results (like 2014-08-21, 2014-08-22) and not before, or later range stuff.

Maybe this is something basic but I tried... well, everything I could think of.

Anyone has any suggestion?

  • Have you checked that you are using the correct syntaxes? I'm not a pro but found these two links that could help you. :) blogs.msdn.com/b/knutbran/archive/2011/06/10/… and dotnetmafia.com/blogs/dotnettipoftheday/archive/2011/12/28/…
    – Tenttu
    Commented Aug 27, 2014 at 5:30
  • @Tenttu - Yes. I read blogs you linked (and many more). This doesn't contains answers I am looking for. Thanks for suggestion anyway. Commented Aug 27, 2014 at 6:07
  • Yep thought so but linked them just to be sure! I'll let you know if I find out any solutions. :)
    – Tenttu
    Commented Aug 27, 2014 at 7:00
  • For the first part, are you asking why it came up with 12:00:00 or why it has that date format (YYYY-MM-DDT00:00:00Z)?
    – John-M
    Commented Aug 29, 2014 at 20:25
  • @John-o Why it came up with 12:00:00? I would expect to use 00:00:00 since the column type is Date only but it looks it splitted the results differently. Commented Aug 29, 2014 at 20:50

3 Answers 3


I think in your refinement panel Xsl, uploaddatedt property is defined as Range Property and not Simple Category. Regarding your first question you already said you have items with that date, So you will get that data only the format that you are getting is weired and to change that you need JavaScript to xsl functions

And your next query could be solved using under given instructions: Try Adding again the Category as shown here below:

      Description="Which department this document is from"
      MoreLinkText="show more" 
      LessLinkText="show fewer"

You can refer this post as well

Try and let us know for any further problem.

  • Already tried that. My current category definition is <Category Title="Upload Date" Description="When the item was last updated" Type="Microsoft.Office.Server.Search.WebControls.ManagedPropertyFilterGenerator" MetadataThreshold="1" NumberOfFiltersToDisplay="100" SortBy="Name" SortDirection="Ascending" ShowMoreLink="False" MappedProperty="uploaddatedt" ShowCounts="Count" /> Commented Sep 1, 2014 at 15:55

The odd time shows up because FAST tries to automatically create 'bins' to put your search results in when you don't tell it exactly how... You said you have many records that have an uploaded date of 21 and 22 August -- FAST figured out the way that it felt like partitioning your results would be to put them into two separate bins with a dividing line likely somewhere near the middle of the result set. This is why you see a refinement selector that can have a time that's not even in your result set, because it conveniently partitioned the results.

To get exact date refinement selectors I would try a few things:

Since the dates are a numeric type, you could manually define the partition arrangement within the refiner's specification using the discretize parameter as described in the MSDN article 'Refiner Specification in the Query Web Service and Query Object Model' -- but every example I've seen of this has the bin boundaries hard-coded like:


... And your refinement bins (for the above example) would still be like: before date 1, date1-date2, date2-date3...after lastDate -- so you wouldn't eliminate the range issue using this technique either.

If you don't really care what time the items were uploaded, I would convert the date value to just the date as Shaamil suggested, this should remove the time from partition consideration and clump your results on dates instead of a huge spectrum of date/times. Also worth noting, since you're still using dates and dates are numeric, you'll still get refinement bins that are ranges (including a before first value, after last value).

You might also consider using the value as text for the purposes of search refinement; if you remove FAST's understanding of the value as a number, the only option it will understand for your value is to treat it as text, and text refines on exact phrases. This will give you refiners that correspond with the precise value of the field you're using.

  • More or less this was my conclusion before asking this question. The problem is that source field is date type (and it should stay like this). I could copy the date to text field but this raises some other (not related) issues. I even tried to be 'smart' and I tried to resolve the issue with calculated column... Commented Sep 1, 2014 at 16:00

Have you tried something like

<xsl:value-of select="ddwrt:FormatDate(@YourDateValue, 1033, 3)"/> 

1033 is the Local and 3rd parameter for the format (Format type are available here)

And hope the server time is synchronised to the exact time zone.

As for the time issue you might need to add 12 hours before saving the value "downloadtime" as SP stores both date and time. A similar issue is discussed here

  • Thx for the input but date formats and zones are not a issue here. The XML data returned by refinement webpart contains data in format as explained in my question. It also includes search records count for each data range. If data range is 'wrong' I can format it as I like, add/subtract time... but then the results will not match. This isn't simple as you suggest. Commented Sep 1, 2014 at 8:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.