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