Turns out this is harder than you would imagine as the underlying xml is missing the data we need, so changing the xslt will not help.
If I use the FAST Search for SharePoint Query Logger on my FAST server, I see that hours, minutes and seconds are returned, so the question is, where do they disappear?
Firing up one of my favorite tools, Reflector, I found the answer in the SharePoint result XML builder, an internal class used to build search result xml - Microsoft.Office.Server.Search.Query.Gateway.XMLBuilder. In the method GetPropertyValue there is a section handling the managed property called write.
and if we take a closer look at GetDateTimeValue we find the answer.
In the last line it formats the date with the d modifier. This stands for short date, and will render a date without hours, seconds and minutes -http://msdn.microsoft.com/en-us/library/az4se3k1.aspx. The siteCulture parameter comes from the search runtime (either the SharePointSearchRuntime or the FASTSearchRuntime, depending on if you are using the built-in search or FAST Search for SharePoint).
My first instinct was to override the formatting of the d modifier for the culture of the running thread. But this will not help as it’s the SSA runtime which executes the query and it is running on a different thread.
Seems your only solution when using the Core Results Web Part is to create a new managed property, and map to it the same crawled properties as is mapped to write. Then use your new managed property instead in the xslt rendering.
If you are using any of the API’s for search, you will get the full date resolution, as the result is not run thru the result XML Builder.