lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <>
Subject [jira] [Updated] (SOLR-9080) DateMath is broken before the year 1582
Date Sun, 08 May 2016 04:59:12 GMT


David Smiley updated SOLR-9080:
    Affects Version/s: 6.0
        Fix Version/s:     (was: 6.0)

> DateMath is broken before the year 1582
> ---------------------------------------
>                 Key: SOLR-9080
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 6.0
>            Reporter: David Smiley
>            Assignee: David Smiley
>             Fix For: 6.1
>         Attachments: SOLR_9080_DateMath_should_not_use_Calendar_API.patch
> 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&*:*&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 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message