lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: Environment Timezone being considered when using SolrJ
Date Wed, 28 Oct 2009 04:38:56 GMT

: I've a wrote a Unit Test in order to simulate the date processing. A high

I think you are missunderstanding what your test is doing, but i'll get to 
that in a second...

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

...if the only time you see a problem is when you use javabin, then a 
testcase demonstrating that (even if it depends on an external Solr port 
being up, ie: the example running on 8983) would be helpful.


i suspect there's a typo in that sentence above, and what you ment to 
write was "dates get SENT BACK with environment UTC offset coordinates" 
... which strictly speaking isn't possible: An "Date" instance (both 
philosophically, and in the java object sense) has no notion of timezone.  
it is a specific point in the one dimensional space of time, and it's 
only when expressing Dates that they wind up being relative to a refrence 
point (ie: a coordinate system in that 1D space) and the concept of 
timezones gets introduced when using a string based representation.

I believe what you are observing is that the *string* representation of 
the data is formatted in UTC -- which is expected, that is a string 
representation of a Date agnostic of any specific timezone.

As for your test...

The reason the assert fails is because you are building 
your Date object using a SimpleDateFormat object, which by default assumes 
any string it parses is in the TimeZone returned by TimeZene.getDefault()
(which is host specific)  You can configure it to assume a different 
TimeZone using the setTimeZone method, or by using a pattern that includes 
a TimeZone pattern letter.

In a nutshell: your dateFormat object doesn't know that the 'Z' at the end 
of the string you are asking it to parse means it's in UTC, so it assumes 
you mean 10:10:10 in *your* timzone.  (If you add a 
"System.out.println(originalDateObject)" this should be clear)  
Meanwhile: Solr does recognize that the 'Z' inticates UTC, hence the 
mismatch in Date objects produced.

:         //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);


View raw message