[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=13232329#comment-13232329 ] David Schlotfeldt commented on SOLR-2690: - Nguyen - Sorry for the slow response. I've been on vacation where I had no Internet. My brain is still on vacation so I might be wrong, but I believe the problem is your aren't rounding the start and end. I believe this will leave the time part of the ranges as 00:00:00.00Z (GMT). The timezone specified by 'tz' simply affects math done with dates (this includes when the gap is incremented). start = 2007-07-30T00:00:00.000Z end = 2007-07-31T00:00:00.000Z gap = +1DAY tz = Asia/Singapore One way to get what you want, which is the way people have been saying to do it, is to adjust the start and end manually. (I believe Singapore is GMT+8) start = 2007-07-30T00:08:00.000Z end = 2007-07-31T00:08:00.000Z gap = +1DAY tz = Asia/Singapore The issue with this approach is your manual adjusting gets tricking when talking about timezones that have day light savings time. This is one place the patch makes things S much easier. So you want to change your test to simply add '/DAY' to the end of each which will round the times to the beginning of the day. Since they rounding takes tz into account it will come out to 8:00. start = 2007-07-30T00:00:00.000Z/DAY end = 2007-07-31T00:00:00.000Z/DAY gap = +1DAY tz = Asia/Singapore Let me know if that helps. (Again, brain not in programming mode yet so I may have completely misunderstood the issue.) 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
[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=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
[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=13196274#comment-13196274 ] David Schlotfeldt commented on SOLR-2690: - Issue with patch. Fixed attached. (Change on line 197 of the patch file) 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
[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=13190089#comment-13190089 ] David Schlotfeldt commented on SOLR-2690: - Thank you Shotaro for posting that code for me. The code Shotaro posted is a new version of faceting that makes date ranges take time zones into account which is essential for the reasons specified above. I also just made DateField and TrieDateField also take time zone into account. Why do we need this? For example let's say you have events in solr. They have a startDate set on them. If we want all events happening today we would want to be able to run the query +startDate[NOW/DAY TO NOW/DAY+1] This query will not work as expected since when /DAY rounds to the beginning of the day for GMT+0. To solve this yes I could run +startDate[NOW/DAY+6HOUR TO NOW/DAY+1+6HOUR] since i am in central timezone. BUT we have daylight savings time so some parts of the year I need it to be +5HOUR instead of +6HOUR. The lack of timezone support makes many date related queries that should be easy hard. The comment above is a patch against https://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_3_3 (from 8/9/2011 which is what i am running off of) that adds a tz parameter that causes the DateMathParser DateField and TrieDateField uses to be configured with the specified timezone. (Though not posted here I also modified the component Shotaro shared with you to use tz if facet.date.tz isn't specified.) 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, 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
[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=13183177#comment-13183177 ] Shotaro Kamio commented on SOLR-2690: - Thanks for David Schlotfeldt's kindness, I'll post his code here on behalf of him. It works with Solr 3.3. Though we need to change the code in order to fit well into solr code base, I post as it is for the first step. The attached tgz contains two java sources which create a custom facet component. The codes are based on SimpleFacets and FacetComponent classes of solr. The following line should be added to solrconfig.xml to use the custom component. searchComponent name=facet class=com.plaudit.core.impl.solr.handler.component.PlauditFacetComponent/ As an example request, date facet request with monthly gap in Tokyo time (GMT+9:00) can be like this: http://localhost:8983/solr/select?indent=onversion=2.2q=*%3A*fq=start=0rows=10fl=*%2Cscoreqt=wt=explanOther=hl.fl=; facet=truefacet.date=manufacturedate_dt facet.date.start=2005-01-31T15:00:00Z facet.date.end=2006-05-31T15:00:00Z facet.date.gap=%2B1MONTH/DAY facet.date.tz=Asia/Tokyo 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. 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=13165058#comment-13165058 ] Shotaro Kamio commented on SOLR-2690: - David, we also faced the date facet gap (rounding) issue. If you can post your patch here, it's very helpful. 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. 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=13076307#comment-13076307 ] Yonik Seeley commented on SOLR-2690: Although this probably isn't a bug, I agree that handling timezones somehow would be nice. We just need to think very carefully about the API so we can support it long term. One immediate thought I had was that it would be a pain to specify the timezone everywhere. Even a simple range query would need to specify it twice: my_date:[(?timeZone=America/Chicago)NOW/YEAR TO (?timeZone=America/Chicago)+1MONTH] So one possible alternative that needs more thought is a TZ request parameter that would apply by default to things that are date related. 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 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=13078292#comment-13078292 ] David commented on SOLR-2690: - Good point. Also, this isn't a bug but if we want a complete solution, we really need a way to specify times in other timezones. If I want midnight in Central time zone I shouldn't have to write: 2011-01-01T06:00:00Z (Note I wrote 6:00 not 0:00) I believe only DateField would have to be modified to make it possible to specify timezone. For a complete example if I wanted to facet blog posts by the date posted and the month: facet.date=blogPostDate facet.date.start=2011-01-01T00:00:00 facet.date.end=2012-01-01T00:00:00 facet.date.gap=+1MONTH timezone=America/Chicago Currently you would need to do the following. (Which actually gives close to correct results but not exact. Again, problem is the gap of +1MONTH doesn't take daylight savings into account so blog posts on the edge of ranges are counted in the wrong range. facet.date=blogPostDate facet.date.start=2011-01-01T00:06:00Z facet.date.end=2012-01-01T00:06:00Z facet.date.gap=+1MONTH 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 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=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
[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=13078578#comment-13078578 ] David Smiley commented on SOLR-2690: Hoss, thanks for elaborating on the distinction between the date literal and the DateMath timezone. I was conflating these issues in my mind -- silly me. 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
