You haven't mentioned what language your update client code is written in
... so i'm not sure what classes "DateTime" and "Convert" are and what
their default behavior is regarding timezones, but w/o that info it's
still pretty clear where your two mistakes are...
: string strStartDate = "26/5/2000 8:38:16 AM";
here's you have a string representation of a date and that string
doesn't contain any TimeZone information -- from this string alone, I (and
the computer) have no way of knowing what absolute moment in time you are
refering to -- is that 8:38:16 AM in *your* local time zone? in *my* local
timezone? in UTC? ... it's unclear.
which means when you ask some code to parse that date...
: DateTime dt = new DateTime();
:
: dt = Convert.ToDateTime(strStartDate);
...it has to make an implicit assumption about what timezone (ie:
coordinate system) that string representation is relative to -- it's
probably picking your local timezone.
Now, in this next bit, you ask your langauge to formate the date as a
string again -- but again you don't give it any instructions as to what
timzeon/coordinate system you want it to use -- so it is (mot likeley)
making the same assumption it did when it parsed your original date
(probably your local TZ, but it doesn't really matter -- whatever it
assumed before it's assuming again, and just outputing the same value with
the fields in differnet order)
You are then forcibly concatenanting a "Z" on the end....
: strStartDate = dt.ToString("yyyy'-'MM'-'dd'T'HH':'mm':'ss'.'fff'Z'");
: AddField(doc, "441", strStartDate); // posting to solr.
...by attaching that Z, you are telling Solr (and any other XML dateTIme
compliant parser) "this string representation of a date is in UTC" ... so
if, back at the top of this email, you really meant "8:38:16 AM in the UTC
time zone" and not ""8:38:16 AM in my local timezone" or "8:38:16 AM in
hoss'ss local timezone" then up to now, you've gotten really lucky and the
value solr knows about matches reallity, but only because you kludged it
that way, not because of well behaved parsing/ormatting logic...
: Query:
http://localhost:8090/solrTest/select/?q=ID%3ASOLR1001&version=2.2&start=0&rows=10&indent=on&fl=441
...:
: <date name="441">2000-05-26T08:38:16Z</date>
Now at query time, when you use SolrJ you will get back a java Date object
representing the absolute moment in that that, when formatted relative the
UTC TZ coordinate system, is displayed as "08:38:16 AM UTC" on that date.
You are then using a simple "toString()" function in java to display the
response, since toString() is a very simplistic method for displaying Date
objects, and doesn't have any mechanism for you to tell it what format you
want the response string in, or what coordinate system (ie: timezone) you
want the string representation to be relateive to, it uses the platform
default timezone...
: ... docs=[SolrDocument[{441=Fri May 26 14:08:16 IST 2000}]]}}
...so aparenty, on the system where you are running this SolrJ query code,
the the java platform default TZ is "IST" which use UTC+05:30, so that
toString() representation does in fact refer to the same abstract moment
in time as the absolute UTC representation you see in the XML -- the fact
taht you are seeing "IST" in that output has nothing to do with Solr, or
SolrJ, it's 100% an artifact of your java setup and the fact that you
called "toString()" on a Date object (instead of using a Date formatter
that you explicitly told "format relative timezone XYZ"
>From the momenent you gave Solr the date string "2000-05-26T08:38:16Z" in
your indexing code, everything after that is 100% consistent, just
represented as strings in differnet timezone coordinate systems depending
on your plaform defaults. but whether or not you gave solr the correct
input string in the first place depends on what you ment by "08:38:16 AM"
-Hoss
