[
https://issues.apache.org/jira/browse/LUCENENET-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13148661#comment-13148661
]
Troy Howard commented on LUCENENET-423:
---------------------------------------
I don't think this is the same debate of ".NET vs Java".
Essentially, two things should be true about any Lucene implementation: the
index files are interchangeable and the same query will return the same results
regardless. How it works under the hood and what the API looks like is where
the debate normally focuses. There's no reason we couldn't enforce
compatibility on the query parser so that it behaves the same on both platforms.
In my opinion this is a bug that needs to be fixed, possibly in both Java
Lucene and .NET Lucene... There should be a standardized method of expressing
dates as strings, which is consistent across all implementations VS just using
whatever the various platforms support via their datetime parser.
> QueryParser differences between Java and .NET
> ---------------------------------------------
>
> Key: LUCENENET-423
> URL: https://issues.apache.org/jira/browse/LUCENENET-423
> Project: Lucene.Net
> Issue Type: Bug
> Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4, Lucene.Net 2.9.4g
> Reporter: Christopher Currens
>
> When trying to do a RangeQuery that uses dates in a certain format, .NET
> behaves differently from its Java counterpart. The code is the same between
> them, but as far as I can tell, it appears that it is a difference in the way
> Java parses dates vs how .NET parses dates. To reproduce:
> {code:java}
> var queryParser = new QueryParser(Lucene.Net.Util.Version.LUCENE_29,
> "FullText", new StandardAnalyzer(Lucene.Net.Util.Version.LUCENE_29));
> var query = queryParser.Parse("Field:[2001-01-17 TO 2001-01-20]");
> {code}
> You'll notice that query looks like the old DateField format (eg
> "0g1d64542"). If you do the same query in Java (or Luke), you'll notice the
> query gets parsed as if it were a RangeQuery of string. AFAIK, Java cannot
> parse a string formatted in that way. If you change the string to use /
> instead of - in the java, you'll get one that uses DateResolutions and
> DateTools.DateToString().
> It seems an appropriate fix for this, if we wanted to keep this behavior
> similar to Java, would be to write our own DateTime parser that behaved the
> same way to Java's parser.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
