Hi Hoss, Thanks for the clarification.
I've a wrote a Unit Test in order to simulate the date processing. A high level detail of this problem is that it occurs only when used the JavaBin custom format (&wt=javabin), in this case the dates get back set with environment UTC offset coordinates. On Thu, Oct 22, 2009 at 11:41 PM, Chris Hostetter <hossman_luc...@fucit.org>wrote: > > : When using SolrJ I've realized document dates are being modified > according > : to the environment UTC timezone. The timezone is being set in the inner > : class ISO8601CanonicalDateFormat of DateField class. > > The dates aren't "modified" based on UTC, they are formated in UTC before > being written to the Lucene index so that no matter what the current > locale is the index format is consistent. > yes, dates are consistent at index. > > : I've read some posts where people say Solr should be most locale and > culture > : agnostic. So, what's the purpose for that timezone processing before > > The use of UTC is specificly to be agnostic of where the server is > running. Any client, any where in the world, using any TimeZone can query > any solr server, running in any JVM, and know that the dates it gets back > are formated in UTC. > > : Code to simulate issue: > > I don't actaully see any "issue" being simulated in this code, can you > elaborate on how exactly it's behaving in a way that's inconsistent with > your expectaitons? (making it a JUNit TestCase that uses assserts to fail > where you are getting data you don't expect is pretty must the universal > way to describe a bug) > import static org.junit.Assert.assertEquals; import java.text.ParseException; import java.text.SimpleDateFormat; import java.util.Date; import org.apache.lucene.document.Field; import org.apache.lucene.document.Field.Index; import org.apache.lucene.document.Field.Store; import org.apache.solr.schema.DateField; import org.junit.Test; public class DateFieldTest { @Test public void shouldReturnSameDateValueWhenDateFieldIsUsedToParseDates() throws ParseException { //Given String originalDateString = "2010-10-10T10:10:10Z"; //When Field field = new Field("field",originalDateString,Store.NO,Index.ANALYZED); DateField dateField = new DateField(); SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'"); Date originalDateObject = dateFormat.parse(originalDateString); Date parsedDate = dateField.toObject(field); //Then assertEquals(originalDateObject, parsedDate); /* TO MAKE TEST PASS * Solr 1.3 * * Comment line 271 at org.apache.solr.schema.DateField * this.setTimeZone(CANONICAL_TZ); */ } } > > My guess would be that you are getting confused by the fact that > Date.toString() uses the default locale of your JVM to generate a string, > which is why the data getting printed out doesn't match the hardcoded > value in your code... > > : System.out.println(dateField.toObject(field)); > > but if you take any Date object you want, print it's toString(), index it, > and then take that indexed string representation convert it back into a > Date (using dateField.toOBject()) you should originalDate.equals(newDate). > I was expecting this behaviour and I get it when performnig an HTTP query and the XMLResponseWriter is used. But the same does not occur when used the BinaryResponseWriter. > > > > -Hoss > > Thanks! Michel