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