lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michel Bottan <>
Subject Re: Environment Timezone being considered when using SolrJ
Date Wed, 28 Oct 2009 19:45:26 GMT
Hi Hoss,

Thanks for the clarification again.

Now I can see where the problem resides. My client application was
formatting date fields using SimpleDateFormat and as you said, it assumes
host timezone configuration.

: 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

That is indeed truth, I did not realize it. Now I am setting up TimeZone to
UTC and the dates are being shown accordingly.


On Wed, Oct 28, 2009 at 2:38 AM, Chris Hostetter

> : 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.
>        ...but...
> 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);
> -Hoss

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message