FAQ
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

Search Discussions

  • Erik Hatcher at Oct 3, 2003 at 3:23 am
    Well, I went ahead and committed my proposed change. Let me know if
    there is any reason why this change would break anything, but I'm
    pretty confident its fine.

    Now the only other issue is that date format must still be SHORT, but
    this shouldn't be as much of a concern as locale - and subclasses can
    tweak that behavior if they choose.

    Erik

    On Thursday, October 2, 2003, at 10:16 PM, Erik Hatcher wrote:

    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

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
    For additional commands, e-mail: lucene-dev-help@jakarta.apache.org

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categorieslucene
postedOct 3, '03 at 2:16a
activeOct 3, '03 at 3:23a
posts2
users1
websitelucene.apache.org

1 user in discussion

Erik Hatcher: 2 posts

People

Translate

site design / logo © 2022 Grokbase