[ 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