Refinement Panel Web Part - Date Ranges

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:

<Category Title="UploadDate" Description="Which department this document is from" Type="Microsoft.Office.Server.Search .WebControls.ManagedPropertyFilterGenerator" MetadataThreshold="1" NumberOfFiltersToDisplay="4" MaxNumberOfFilters="20" ShowMoreLink="True" MappedProperty="uploaddatedt" MoreLinkText="show more" LessLinkText="show fewer" ShowCounts="Count" /> 

You can refer this post as well

Try and let us know for any further problem.

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:

write(discretize=manual/2010-01-01/2010-08-22/2010-09-15/2010-09-21/2010-09-22)

... 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.

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