David Smiley created SOLR-9080:
----------------------------------

             Summary: DateMath is broken before the year 1582
                 Key: SOLR-9080
                 URL: https://issues.apache.org/jira/browse/SOLR-9080
             Project: Solr
          Issue Type: Bug
            Reporter: David Smiley
             Fix For: 6.0


In Solr 6.0, dates are parsed using the Java 8 java.time API.  It formerly was 
parsed using java.util.SimpleDateFormat which uses java.util.GregorianCalendar. 
 I've learned that the java.time API does _not_ switch to a different algorithm 
at the Gregorian Change Date (year 1582) whereas GregorianCalendar does.  A 
ramification of this is that the milliseconds before epoch value is different 
between the APIs for dates prior to this year.  They both round-trip between 
themselves but not between each other prior to this date.  Thus, anyone 
indexing historical dates must re-index when moving to Solr 6.

What was _not_ changed in the parsing code was Solr's date-math logic -- it 
still uses the Calendar API.  This works for dates after 1582 but before, it'll 
introduce discrepancies.  Here's an example showing weird behavior:
http://localhost:8983/solr/techproducts/select?facet.range.end=1400-01-01T00:00:00Z&facet.range.gap=%2B10YEARS&facet.range.start=1300-01-01T00:00:00Z/YEAR&facet.range=manufacturedate_dt&facet=on&indent=on&q=*:*&rows=0&wt=json
Note that the year 1300 rounded down to the year, becomes 1299 January 8th 
(weird in and of itself) and that subsequent gaps start on the 9th.

{noformat}
"counts":[
          "1299-01-08T00:00:00Z",0,
          "1309-01-09T00:00:00Z",0,
          "1319-01-09T00:00:00Z",0,  ...
{noformat}

This weirdness will show itself for units at the year or month level, but not 
below that (from what I'm seeing).  In other words, if facet.range.gap is at 
this amount, or otherwise using the date math syntax to round or add a year or 
month, there will be issues like this.  Otherwise there doesn't seem to be an 
issue.

I think the solution is clearly to switch the date math code to use the 
java.time API.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to