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

Reply via email to