[jira] [Commented] (SOLR-2690) Date Math should allow clients to override timezone used for rounding (faceting queries)
[ https://issues.apache.org/jira/browse/SOLR-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13264613#comment-13264613 ] David Schlotfeldt commented on SOLR-2690: - Sorry I'm not familiar with Solr's SVN layout. What SVN location do I look at? The trunk? A branch? What files were changed? Are all the changes you made in revision 1329837 Date Math should allow clients to override timezone used for rounding (faceting queries) -- Key: SOLR-2690 URL: https://issues.apache.org/jira/browse/SOLR-2690 Project: Solr Issue Type: Improvement Reporter: David Schlotfeldt Assignee: Hoss Man Fix For: 4.0 Attachments: SOLR-2690.patch, SOLR-2690.patch, SOLR-2690.patch, 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. -- 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
[jira] [Commented] (SOLR-2690) Date Faceting or Range Faceting doesn't take timezone into account.
[ https://issues.apache.org/jira/browse/SOLR-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13078352#comment-13078352 ] David Schlotfeldt commented on SOLR-2690: - By extending FacetComponent (and having to resort to reflection) I added: facet.date.gap.tz The new parameter only affects the gap. The math done with processing the gap is the largest issue when it comes it date faceting in my mind. I would be more then happy to provide a patch to add this feature. No this doesn't address all timezone issues but at least it would address the main issue that makes date faceting, in my eyes, completely useless. I bet there are 100s of people out there using date faceting that don't realize it does NOT give correct results :) 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: Bug Affects Versions: 3.3 Reporter: David Schlotfeldt 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. 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
[jira] [Commented] (SOLR-2690) Date Faceting or Range Faceting doesn't take timezone into account.
[ https://issues.apache.org/jira/browse/SOLR-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13078419#comment-13078419 ] David Schlotfeldt commented on SOLR-2690: - Okay I've modified my code to now take facet.date.tz instead. The time zone now affects the facet's start, end and gap values. 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: Bug Affects Versions: 3.3 Reporter: David Schlotfeldt 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. 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
[jira] [Commented] (SOLR-2690) Date Faceting or Range Faceting doesn't take timezone into account.
[ https://issues.apache.org/jira/browse/SOLR-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13078538#comment-13078538 ] David Schlotfeldt commented on SOLR-2690: - Being able to specify dates in timezones other then GMT+0 isn't a problem. It would just be nice but we can gnore that. The time zone the DateMathParser is configured with is the issue (which it sounds like you understand.) My solution that changes the timezone DateMathParser is constructed with in SimpleFacet to parse start, end and gap isn't ideal. I went this route because I don't want to run a custom built Solr -- my solution allowed me to fix the bug by simply replacing the facet SearchComponent. Affecting all DateMathParsrs created for length of the request is what is really needed (which is what you said). I like your approach. It sounds like we are on the same page. So, can we get this added? :) Without time zone affecting DateMathParser the date faceting is useless (at least for 100% the situations I would use it for) By the way, I'm gald to see how many responses there have been. I'm happy to see how active this project is. :) 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 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. 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
