[ 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