: If you index a Java date object instead of the text format, it will be : valid in the timezone at the client, and SolrJ will do timezone : translation before sending to Solr. Solr will index/store the date in UTC.
this is missleading -- SolrJ doesn't do any sort of "timezone translation" ... a Java Date object represents an absolute fixed moment in time, there is no timezone information in it. If your client code builds a Date object from some intial string, then at the moment *you* parse hat string, you are either explcitly or implicitly assuming some TZ information about the string representation when converting it into an absolute moment in time to build the Date object -- likewise, when executing a search and fetching responses, SolrJ will give you back a Data object (representing an absolute moment in time) and if *you* format that date as a string, you are either explcitly or implicitly assuming some TZ information about the string representation when converting it from a Date object (representing that absolute moment in time) Internally in SolrJ and Solr, Dates are always either Date objects (representing absolute moments in times) or they are Strings or longs representing that absolute moment in time relative to the UTC TZ coordinate space. Bottom line: if you are not seeing the correct "time" then some assumption is probaly being violated somewhere in your client code as far as the conversaion to/from string values -- if you gather up and look at: 1) your indexing code 2) a sample query URL done from the browser 3) the XML/json results from that sample query in your browser 4) your searching code excuting the same query in SolrJ 5) the output of your SolrJ search code ...the problem may become obvious, but if not is not, then sending all of those things in a reply will help us point out where any discrepencies might be. -Hoss
