Re: Ambiguous response on TrieDateField

[Shawn Heisey <ap...@elyograg.org>]

On 8/3/2017 3:48 PM, Imran Rajjad wrote:
> I have observed a difference of Day in TrieDateField when queried from Solr Cloud web interface and SolrK (Java API)
>
> Below is the query response from Web Interface
>
> {
>   "responseHeader":{
>     "zkConnected":true,
>     "status":0,
>     "QTime":22,
>     "params":{
>       "q":"id:01af04e1-83ce-4eb0-8fb5-dc737115dcce",
>       "indent":"on",
>       "fl":"dateTime",
>       "sort":"dateTime asc, id asc",
>       "rows":"100",
>       "wt":"json",
>       "_":"1501792144786"}},
>   "response":{"numFound":1,"start":0,"docs":[
>       {
>         "dateTime":"2017-06-17T00:00:00Z"}]
>   }}
>
> The same query run from SolrJ shows previous day in the same field

This is a timezone issue.

Solr itself only stores dates and thinks in terms of the UTC timezone
(universal time constant).  It is possible with date math (using the NOW
keyword) to inform Solr of the timezone so it calculates day boundaries
correctly, but that doesn't change what gets stored and displayed in a
JSON response.

What I quoted above is the text response you are getting (in JSON
format) from the admin UI.  When the response is text-based (JSON or XML
usually), that ISO format is the only thing you are going to get.

SolrJ gets responses in Javabin.  Because this format is a binary
representation of the Java object, rather than text, when SolrJ receives
that information, the dateTime field is a Java date object of some kind,
which is timezone aware, and is going to be populated with the UTC
information stored in Solr.

Whatever you are using for output from the SolrJ response is converting
the Java object to a timezone-specific text representation.  This
happens by default when you use the "toString()" method, which is what
Java calls when you print it without calling any method.

The output is showing up in the PDT (Pacific Daylight Time) timezone,
which is probably the system timezone on the computer that's running the
SolrJ program.  That timezone is 7 hours behind UTC, so midnight on the
17th (what is actually stored in Solr) becomes 5 PM on the 16th.  When
the timezone for the SolrJ program switches to Pacific Standard Time a
few months from now, that display will change to 8 hours behind UTC.

Solr and your SolrJ program are behaving exactly as they are designed. 
The only reasonable way to handle date/time objects with computer
systems is to have the server store them in UTC and the user-facing
program translate them to a local timezone.

Thanks,
Shawn