QueryParser can only handle DateFormat.SHORT formats within the default
locale currently. This can be fixed by adding another QueryParser
constructor parameter (and another static parse method to match)
accepting the locale to use for date format conversion - existing API
would still work fine.
Does anyone have any reasons why allowing an optional Locale to be
passed in and used (defaulting to the default Locale, of course)
shouldn't be implemented? Thankfully a custom QueryParser subclass can
take care of this problem already, but its not very elegant.
The issue would manifest itself if a European entered 31/12/03 into a
search box (within a date range) but the server is running in the US
and would use the US locale to format with. With my patch, application
developers would be responsible for setting the locale (probably from
the HTTP request sent by the browser) appropriately.
Thanks,
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
