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

Nguyen Kien Trung commented on SOLR-2690:
-----------------------------------------

hi David, I'm one of 100s people having this issue. I applied your patch on 
3.3, and modified the {{SimpleFacetsTest}} to cover a simple timezone test 
scenario. However, the tests for {{DateField}} and {{TrieDateField}} fail. Is 
there an additional changes need to be made on SimpleFacets?

{code:lang=java|title=SimpleFacetsTest#indexDateFacets}
    add_doc(i, "2012", f, "2007-07-30T07:07:07.070Z");
    add_doc(i, "2015", f, "2007-07-30T23:07:07.070Z"); // one more record
{code}

{code:lang=java|title=SimpleFacetsTest#helpTestDateFacets}
    ...
    final String jul4 = rangeMode ? "[.='1'  ]" : "[.='2'  ]";
    
    assertQ("check counts for day of facet by day using UTC timezone",
            req( "q", "*:*"
                ,"rows", "0"
                ,"facet", "true"
                ,p, f
                ,p+".start", "2007-07-30T00:00:00.000Z"
                ,p+".end",   "2007-07-31T00:00:00.000Z"
                ,p+".gap",   "+1DAY"
                ,"tz", "UTC"
                )
            ,"*[count("+pre+"/int)="+(rangeMode ? 1 : 1)+"]"
            ,pre+"/int[@name='2007-07-30T00:00:00Z'][.='2']"
            );
    
    assertQ("check counts for day of facet by day using Asia/Singapore (UTC+8) 
timezone",
            req( "q", "*:*"
                ,"rows", "0"
                ,"facet", "true"
                ,p, f
                ,p+".start", "2007-07-30T00:00:00.000Z"
                ,p+".end",   "2007-07-31T00:00:00.000Z"
                ,p+".gap",   "+1DAY"
                ,"tz", "Asia/Singapore"
                )
            ,"*[count("+pre+"/int)="+(rangeMode ? 1 : 1)+"]"
            ,pre+"/int[@name='2007-07-30T00:00:00Z'][.='1']"
            );    // fail here, still returns 2 instead of 1, already set 
tests.timezone parameter to UTC to make sure data indexed in UTC
    ...
{code}
                
> Date Faceting or Range Faceting doesn't take timezone into account.
> -------------------------------------------------------------------
>
>                 Key: SOLR-2690
>                 URL: https://issues.apache.org/jira/browse/SOLR-2690
>             Project: Solr
>          Issue Type: Improvement
>    Affects Versions: 3.3
>            Reporter: David Schlotfeldt
>         Attachments: add-tz-parameter.patch, add-tz-parameter.patch, 
> timezone-facet-component.tgz
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> Timezone needs to be taken into account when doing date math. Currently it 
> isn't. DateMathParser instances created are always being constructed with 
> UTC. This is a huge issue when it comes to faceting. Depending on your 
> timezone day-light-savings changes the length of a month. A facet gap of 
> +1MONTH is different depending on the timezone and the time of the year.
> I believe the issue is very simple to fix. There are three places in the code 
> DateMathParser is created. All three are configured with the timezone being 
> UTC. If a user could specify the TimeZone to pass into DateMathParser this 
> faceting issue would be resolved.
> Though it would be nice if we could always specify the timezone 
> DateMathParser uses (since date math DOES depend on timezone) its really only 
> essential that we can affect DateMathParser the SimpleFacets uses when 
> dealing with the gap of the date facets.
> Another solution is to expand the syntax of the expressions DateMathParser 
> understands. For example we could allow "(?timeZone=VALUE)" to be added 
> anywhere within an expression. VALUE would be the id of the timezone. When 
> DateMathParser reads this in sets the timezone on the Calendar it is using.
> Two examples:
> - "(?timeZone=America/Chicago)NOW/YEAR"
> - "(?timeZone=America/Chicago)+1MONTH"
> I would be more then happy to modify DateMathParser and provide a patch. I 
> just need a committer to agree this needs to be resolved and a decision needs 
> to be made on the syntax used
> Thanks!
> David

--
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

        

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

Reply via email to