[
https://issues.apache.org/jira/browse/SOLR-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 SOOOO 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: [email protected]
For additional commands, e-mail: [email protected]
