[ https://issues.apache.org/jira/browse/SOLR-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hoss Man resolved SOLR-544. --------------------------- Resolution: Fixed Assignee: Hoss Man patch in SOLR-470 both improves the documentation regarding trailing zeros in addition to adding a parser that ensures all dates are in the canonical format. Committed revision 658003. > Dates with "optional" milliseconds are not equivilent > ----------------------------------------------------- > > Key: SOLR-544 > URL: https://issues.apache.org/jira/browse/SOLR-544 > Project: Solr > Issue Type: Bug > Affects Versions: 1.1.0, 1.2, 1.3 > Reporter: Hoss Man > Assignee: Hoss Man > Fix For: 1.3 > > > Something that occured to me while working n SOLR-470 is that since the > earliest versions of Solr, "DateField" has advertised it's format as... > bq. date field shall be of the form "1995-12-31T23:59:59Z" The trailing "Z" > designates UTC time and is mandatory. Optional fractional seconds are > allowed: "1995-12-31T23:59:59.999Z" All other parts are mandatory. > The problem is that Solr has always remained happily ignorant about wether > you were using milliseconds or not, even in the case of "0" milliseconds, so > the following input strings do not result in Terms which are truly equal... > * 1995-12-31T23:59:59Z > * 1995-12-31T23:59:59.0Z > * 1995-12-31T23:59:59.00Z > * 1995-12-31T23:59:59.000Z > ...which means if people are inconsistent about how they interact with > DateField (sometimes including the millis and sometimes not including them) > the can get incorrect behavior in various situations: > * sorting by date with a secondary sort can cause hte secondary sort to be > ignored when the dates should be considered equal. > * range queries might miss items equal to the end points but with > fewer/more characters then the input > Any solution would require true parsing & normalizing of any date input > (currently dates are only parsed if they involve DateMath) and complete > reindexing > NOTE: I don't personally think fixing this issue in DateField is worthwhile. > i think it would be better to document it as a caveat and require people to > be consistent in their usage of milliseconds (ie: if you are going to use > them, then always use them even if they are 0). > Instead we should probably focus on a new Long based Date Field (see > SOLR-440) since that would always require parsing to get to the internal > representation anyway. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.