[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064245#comment-13064245 ]
Vinicius Barros commented on LUCENE-1768: ----------------------------------------- Hi Robert, Thanks for the script, it helped me to find a case where it fails. On my JRE, the code below fails: {code} SimpleDateFormat df = (SimpleDateFormat) DateFormat.getDateTimeInstance( DateFormat.FULL, DateFormat.LONG, new Locale("de_CH")); // most of date pattern do not include era, so we add it here. Also, // sometimes second is not available, we make sure it's present too df.applyPattern(df.toPattern() + " G s Z yyyy"); df.setTimeZone(TimeZone.getTimeZone("America/Grand_Turk")); long l1 = -1881411016000l; long l2 = -1881411028000l; String d1 = df.format(new Date(l1)); String d2 = df.format(new Date(l2)); long newL1 = df.parse(d1).getTime(); long newL2 = df.parse(d2).getTime(); System.out.println(l1 + " => " + d1 + " => " + newL1); System.out.println(l2 + " => " + d2 + " => " + newL2); assertEquals(l1, newL1); assertEquals(l2, newL2); {code} and it outputs: {code} -1881411016000 => Friday, May 20, 1910 4:42:32 AM EST => -1881411448000 -1881411028000 => Friday, May 20, 1910 4:42:20 AM EST => -1881411460000 {code} As you can see, it seems DateFormat is not very reliable and do not convert back and forth from date(long) to string format and vice-versa. I am planning to add a sanity check when creating randomly the date format, the check will check whether the date can be converted to/from long from/to string without data loss. What do you think? > NumericRange support for new query parser > ----------------------------------------- > > Key: LUCENE-1768 > URL: https://issues.apache.org/jira/browse/LUCENE-1768 > Project: Lucene - Java > Issue Type: New Feature > Components: core/queryparser > Affects Versions: 2.9 > Reporter: Uwe Schindler > Assignee: Uwe Schindler > Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor > Fix For: 4.0 > > Attachments: week-7.patch, week1.patch, week2.patch, week3.patch, > week4.patch, week5-6.patch > > > It would be good to specify some type of "schema" for the query parser in > future, to automatically create NumericRangeQuery for different numeric > types? It would then be possible to index a numeric value > (double,float,long,int) using NumericField and then the query parser knows, > which type of field this is and so it correctly creates a NumericRangeQuery > for strings like "[1.567..*]" or "(1.787..19.5]". > There is currently no way to extract if a field is numeric from the index, so > the user will have to configure the FieldConfig objects in the ConfigHandler. > But if this is done, it will not be that difficult to implement the rest. > The only difference between the current handling of RangeQuery is then the > instantiation of the correct Query type and conversion of the entered numeric > values (simple Number.valueOf(...) cast of the user entered numbers). > Evenerything else is identical, NumericRangeQuery also supports the MTQ > rewrite modes (as it is a MTQ). > Another thing is a change in Date semantics. There are some strange flags in > the current parser that tells it how to handle dates. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org