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