[
https://issues.apache.org/jira/browse/LUCENENET-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Currens closed LUCENENET-423.
-----------------------------------------
Resolution: Fixed
Fixed with LUCENENET-478. Either it was old or ported incorrectly, but the
Java version uses DateFormat.SHORT to parse the date, which has a .NET
equivalent.
It's not a perfect port, however. With java, in my locale, these two string
parse just fine in java:
"1/1/2002" and "1/1/2002jab89034jh134oijgb"
They will both return the same date. With .NET, the latter fails. Mostly for
performance reasons, I didn't want to first TryParseExact the string and then
check try to emulate Java. Seems like something we could document for those
who want to use DateFields in 3.x.
If Version.LUCENE_29 or earlier is passed to the QueryParser, the old behavior
where .NET parses more dates than Java does, specifically dates with dashes
instead of forward slashes, for those who want the old behavior.
> 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
