Mailing List Archive: Lucene: Java-Dev

[jira] [Updated] (SOLR-2690) Date Math should allow clients to override timezone used for rounding (faceting & queries)

Index | Next | Previous | View Threaded

jira at apache

Apr 10, 2012, 3:53 PM

Post #1 of 3 (93 views)
Permalink

[jira] [Updated] (SOLR-2690) Date Math should allow clients to override timezone used for rounding (faceting & queries)

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

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

Description:
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.

was:
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

Affects Version/s: (was: 3.3)
Assignee: Hoss Man
Summary: Date Math should allow clients to override timezone used for rounding (faceting & queries) (was: Date Faceting or Range Faceting doesn't take timezone into account.)

editing summary & description to clarify this isn't just about faceting, but date math in general.

> Date Math should allow clients to override timezone used for rounding (faceting & queries)
> ------------------------------------------------------------------------------------------
>
> Key: SOLR-2690
> URL: https://issues.apache.org/jira/browse/SOLR-2690
> Project: Solr
> Issue Type: Improvement
> Reporter: David Schlotfeldt
> Assignee: Hoss Man
> 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.

--
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 [at] lucene
For additional commands, e-mail: dev-help [at] lucene

jira at apache

Apr 13, 2012, 8:01 PM

Post #2 of 3 (82 views)
Permalink

[jira] [Updated] (SOLR-2690) Date Math should allow clients to override timezone used for rounding (faceting & queries) [In reply to]

[ 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

updated patch with tests.

still a few TODOs and nocommits related to validating the TZ param: TimeZone.getTimeZone happily accepts gibberish and returns GMT instead -- which would be really confusing if Solr is running on a server with an older tzdata file and the client tried to specify some relatively new timezone, silently getting GMT instead.

There is a TimeZone.getAvailableIDs method that we could use to do a quick check, but that would only cover named TimeZones (ie: "America/Los_Angeles") so we have to explicitly validate if it's a legal "CustomID" (ie: "GMT+/-\d+) ... need another 30 minutes or so at some point to wrap that logic up into a static utility that can be used by both SolrRequestInfo and the test classes

> Date Math should allow clients to override timezone used for rounding (faceting & queries)
> ------------------------------------------------------------------------------------------
>
> Key: SOLR-2690
> URL: https://issues.apache.org/jira/browse/SOLR-2690
> Project: Solr
> Issue Type: Improvement
> Reporter: David Schlotfeldt
> Assignee: Hoss Man
> Attachments: SOLR-2690.patch, 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.

--
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 [at] lucene
For additional commands, e-mail: dev-help [at] lucene

jira at apache

Apr 23, 2012, 10:51 PM

Post #3 of 3 (71 views)
Permalink

[jira] [Updated] (SOLR-2690) Date Math should allow clients to override timezone used for rounding (faceting & queries) [In reply to]

[ 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

Updated patch, adds TimeZoneUtils (with tests) to do what TimeZone.getTimeZone should have done in the first place.

I think this is ready to go.

any feedback from anyone on the overall approach?

> Date Math should allow clients to override timezone used for rounding (faceting & queries)
> ------------------------------------------------------------------------------------------
>
> Key: SOLR-2690
> URL: https://issues.apache.org/jira/browse/SOLR-2690
> Project: Solr
> Issue Type: Improvement
> Reporter: David Schlotfeldt
> Assignee: Hoss Man
> Attachments: SOLR-2690.patch, SOLR-2690.patch, 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.

--
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 [at] lucene
For additional commands, e-mail: dev-help [at] lucene

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads