lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SOLR-2690) Date Faceting or Range Faceting doesn't take timezone into account.
Date Tue, 10 Apr 2012 22:49:17 GMT

     [ https://issues.apache.org/jira/browse/SOLR-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Hoss Man updated SOLR-2690:
---------------------------

    Attachment: SOLR-2690.patch

David: I like the theory of your patch, but the implementation choices you made seem a little
heavy handed.  In particular I don't understand the need for your ExecuteWithThreadDateMathParser
-- as i mentioned, the DateMathParser class already uses SolrRequestInfo to define the default
"NOW", we can use similar logic to define a default TZ w/o introducing as much complexity.

I whipped up a quick patch that takes this approach -- please take a look and lemme know what
you think.  I did some quick manual testing and everything seems to be working, but obviously
we need some good unit tests before we can commit (not sure when i'll have a chance to work
on this so feel free to jump in if you want)

bq. The timezone specified by 'tz' simply affects math done with dates 

Right -- this is really the only sane way for this to work -- if the client specifies an absolute
time for start/end when faceting, we *have* to use that absolute time, we can't assume they
mean for that to be "rounded" in some way relative the client's timezone -- rounded to what
precision? Day? Month? Year?).

Another digression...

bq. 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. ... The issue with this approach is your "manual" adjusting
gets tricking when talking about timezones that have day light savings time. 

You should never "manually adjust" times before sending them to solr -- If you have an absolute
abstract moment in time, then you should format that abstract moment of time as string using
then canonical solr date format (which requires the use of UTC in the format).  If you are
starting with a string representation of some absolute abstract moment of time that has been
formated using some other arbitrary format and/or timezone, you should _parse_ it into an
abstract moment in time (using a date parsing library that knows about the rules of your timezone
-- any decent one should know about all the timezone data), and *then* format that abstract
moment of time as string using the canonical solr date format.



                
> 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: 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.
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message