[jira] [Commented] (SOLR-2690) Date Faceting or Range Faceting doesn't take timezone into account.

["Nguyen Kien Trung (Commented) (JIRA)" <ji...@apache.org>]

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org