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.
Michel
On Wed, Oct 28, 2009 at 2:38 AM, Chris Hostetter
<hossman_luc...@fucit.org>wrote:
>
> : 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
>
>
