lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SOLR-2690) Date Faceting or Range Faceting doesn't take timezone into account.
Date Tue, 02 Aug 2011 23:56:27 GMT

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

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

    Issue Type: Improvement  (was: Bug)

bq. 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)

"Central time zone" is a vague concept that may mean one thing to you, but may mean something
different to someone else.  For any arbitrary moment in the (one dimensional) space of time
values, there are an infinite number of ways to represent that time as a string (or as number)
depending on where you place your origin for the coordinate system.  Requiring that clients
format times in UTC is no different then requiring clients to use Arabic numerals to represent
integers -- it's just a matter of making sure there is no ambiguity, and everyone is using
the same definition of "0".  UTC is a completely unambiguous coordinate system for times,
that is guaranteed to work in any JVM that Solr might run on.  Even if we added code to allow
dates to be expressed in arbitrary user selected timezones, we couldn't make that garuntee.

Bottom line: the issue of parsing/formatting times in other coordinate systems (ie: timezones)
should not be convoluted with the issue of what timezone is used by the DateMathParser when
rounding -- those are distinct issues.  It's completely conceivable to have a QParser that
accepts a variety of data formats and "guesses" what TZ is meant and use that QParser in the
same request where you want date faceting based on a TZ that is specified distinctly from
the query string (ie: user's local TZ is UTC-0700, but they are searching for records dated
before "Dec 15, 2010 4:20PM EST")

bq. So one possible alternative that needs more thought is a "TZ" request parameter that would
apply by default to things that are date related.

Right ... from the beginning DateMathparser was designed with the hope that a TZ/Locale pair
could be specified per request (or per field declaration) for driving the rounding/math logic,
there was just no sane way to specify an alternative to UTC/US that could be past down into
the DateMathParser and used ubiquitously in a request because of the FieldType API.

(Slight digression...

bq. its really only essential that we can affect DateMathParser the SimpleFacets uses when
dealing with the gap of the date facets.

...just changing the TZ used by that instance of DateMathParser for rounding/math isn't going
to do any good if the user then tries to filter on one of those constraints and the filter
query code winds up using the defaults in DateField (ie: NOW/DAY and NOW/DAY+1HOUR are going
to be very differnet things in the facet count code path vs the filter query code path))

Now that we have SolrRequestInfo and a request param to specify the meaning of "NOW", the
same logic could be used to allow a request param to specify the TZ/Locale properties of the
DateMathParser as well.

But like I said: this should really only be used to affect the *math* in DateMathParser --
it should not be used in DateField.parseDate/formatDate because DateField by definition deals
with a single canonical time format, by the time the DateField class is involved in dealing
with a Date everything should be un-ambiguisly expressable in UTC.

logic for parsing date strings that aren't in the canonical date format should be a QParser
responsibility at query time, or an UpdateProcessor responsibility at index time.  Logic for
formatting dates in non-canonical format should be a ResponseWriter responsibility.  This
new request property we're talking about for defining the "users TZ" can certainly be used
in all of these places to pick/override defaults, but that type of logic really doesn't belong
in DateField.

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


Mime
View raw message