[
https://issues.apache.org/jira/browse/LUCENENET-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236155#comment-13236155
]
Christopher Currens commented on LUCENENET-423:
-----------------------------------------------
For backwards compatibility, I've decided it's probably best to implement this
conditionally based on the Version passed to the QueryParser's constructor.
>From LUCENE_30 and onward, it will now parse the dates similar to how java
>does it, using on the ShortDatePattern on the CurrentCulture's FormatInfo.
>The old behavior of parsing any date style will be present if any earlier
>version is specified.
> QueryParser differences between Java and .NET when parsing range queries
> involving dates
> ----------------------------------------------------------------------------------------
>
> 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
> Fix For: Lucene.Net 3.0.3
>
>
> 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