lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (SOLR-9080) DateMath is broken before the year 1582
Date Sat, 14 May 2016 04:27:12 GMT


ASF subversion and git services commented on SOLR-9080:

Commit 8309bae5ff11c6c9e5835c60b6f8b08bd810737d in lucene-solr's branch refs/heads/branch_6_0
from [~dsmiley]
[;h=8309bae ]

SOLR-9080 SOLR-9085: Fix date math before the year 1582.
note: DateMathParser no longer needs a Locale
(cherry picked from commit 4193e60)
(cherry picked from commit 9d826ff)

> 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, 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