You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Robert Muir (JIRA)" <ji...@apache.org> on 2011/01/23 17:12:08 UTC

[jira] Commented: (SOLR-1916) investigate DIH use of default locale

    [ https://issues.apache.org/jira/browse/SOLR-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985354#action_12985354 ] 

Robert Muir commented on SOLR-1916:
-----------------------------------

I investigated and dove in... definitely a pretty big/invasive change here.

My approach was to require locale and timezone to be mandatory parameters for DIH... even then
I ended up having to modify a huge amount of code to try to prevent any problems.

My recommendation for 3.1 would be to take the warning that was in Solr 1.4.1 and add it to DIH's CHANGES.txt
for the release, but additionally recommending that you set -Duser.timezone to match the database tz...
(I think, I am not a timezone policeman!)


> investigate DIH use of default locale
> -------------------------------------
>
>                 Key: SOLR-1916
>                 URL: https://issues.apache.org/jira/browse/SOLR-1916
>             Project: Solr
>          Issue Type: Task
>          Components: contrib - DataImportHandler
>    Affects Versions: 3.1, 4.0
>            Reporter: Robert Muir
>            Priority: Blocker
>             Fix For: 3.1, 4.0
>
>
> This is a spinoff from LUCENE-2466.
> In this issue I changed my locale to various locales and found some problems in Lucene/Solr triggered by use of the default Locale.
> I noticed some use of the default-locale for Date operations in DIH (TimeZone.getDefault/Locale.getDefault) and, while no tests fail, I think it might be better to support a locale parameter for this.
> The wiki documents that numeric parsing can support localized numerics formats: http://wiki.apache.org/solr/DataImportHandler#NumberFormatTransformer
> In both cases, I don't think we should ever use the default Locale. If no Locale is provided, I find that new Locale("") <-- Unicode Root Locale, is a better default for a server situation in a lot of cases, as it won't change depending on the computer, or perhaps we just make Locale params mandatory for this.
> Finally, in both cases, if localized numbers/dates are explicitly supported, I think we should come up with a test strategy to ensure everything is working. One idea is to do something similar to or make use of Lucene's LocalizedTestCase.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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