[
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: [email protected]
For additional commands, e-mail: [email protected]
