[
https://issues.apache.org/jira/browse/LUCENENET-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13148616#comment-13148616
]
Christopher Currens commented on LUCENENET-423:
-----------------------------------------------
I still don't know 100% how I feel about this. To be honest, I guess I don't
understand the group's stance on how compatible we want to be with java. I
don't want to get into it too deep here, but my understanding is we wanted to
be as close to java as possible, and the differences in how .NET and Java can
parse a datetime seem minor, but are just as important, in my opinion.
The problem is that .NET actually can parse more kinds of strings into date
times than Java, and that may not be a bad thing, a .NET developer may expect
that, but the difference in behavior is still my main concern. Either way, I'm
willing to go in whatever direction the group decides.
> 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
