Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Query_String query inclusive date range is not "inclusive" #20579

Closed
WojciechLuczkow opened this issue Sep 20, 2016 · 2 comments
Closed

Query_String query inclusive date range is not "inclusive" #20579

WojciechLuczkow opened this issue Sep 20, 2016 · 2 comments

Comments

@WojciechLuczkow
Copy link

Elasticsearch version: 2.4.0

Plugins installed: []

JVM version: Java HotSpot 64-bit Server VM (build 25.65-b01, mixed mode)

OS version: Windows 7 SP 1

Description of the problem including expected versus actual behavior:

When searching date field using query_string query and providing timestamp like:

[2016-09-13 TO 2016-09-20] the entry with timestamp field being 2016-09-20T08 is not matched - same with curly brackets i.e. {2016-09-13 TO 2016-09-20}
[2016-09-13 TO 2016-09-20T09] works (but [2016-09-13 TO 2016-09-20T08] not)

I have just migrated from 1.7.5 to 2.4.0 and in 1.7.5 above query was returning correct, in my understanding, results.

Steps to reproduce:

  1. Perform search using query_string query for inclusive date range [yyyy-mm-dd TO yyyy-mm-dd] and provide date with day but without hour
@jpountz
Copy link
Contributor

jpountz commented Sep 20, 2016

I can reproduce on master with the following recreation

PUT test/test/1
{
  "date": "2016-09-07T14:55:30Z"
}

PUT test/test/2
{
  "date": "2016-09-09T11:07:59Z"
}

GET test/_search
{
  "query": {
    "query_string": {
      "default_field": "date",
      "query": "[2016-09-07 TO 2016-09-09]"
    }
  }
}

Only document 1 matches the query, not 2.

@jpountz
Copy link
Contributor

jpountz commented Sep 20, 2016

However things still work if the rounding is explicit:

GET test/_search
{
  "query": {
    "query_string": {
      "default_field": "date",
      "query": "[2016-09-07 TO 2016-09-09||/d]"
    }
  }
}

jpountz added a commit to jpountz/elasticsearch that referenced this issue Oct 7, 2016
Elasticsearch 1.x used to implicitly round up upper bounds of queries when they
were inclusive so that eg. `[2016-09-18 TO 2016-09-20]` would actually run
`[2016-09-18T00:00:00.000Z TO 2016-09-20T23:59:59.999Z]` and include dates like
`2016-09-20T15:32:44`. This behaviour was lost in the cleanups of elastic#8889.

Closes elastic#20579
jpountz added a commit that referenced this issue Oct 7, 2016
Elasticsearch 1.x used to implicitly round up upper bounds of queries when they
were inclusive so that eg. `[2016-09-18 TO 2016-09-20]` would actually run
`[2016-09-18T00:00:00.000Z TO 2016-09-20T23:59:59.999Z]` and include dates like
`2016-09-20T15:32:44`. This behaviour was lost in the cleanups of #8889.

Closes #20579
jpountz added a commit that referenced this issue Oct 7, 2016
Elasticsearch 1.x used to implicitly round up upper bounds of queries when they
were inclusive so that eg. `[2016-09-18 TO 2016-09-20]` would actually run
`[2016-09-18T00:00:00.000Z TO 2016-09-20T23:59:59.999Z]` and include dates like
`2016-09-20T15:32:44`. This behaviour was lost in the cleanups of #8889.

Closes #20579
jpountz added a commit that referenced this issue Oct 7, 2016
Elasticsearch 1.x used to implicitly round up upper bounds of queries when they
were inclusive so that eg. `[2016-09-18 TO 2016-09-20]` would actually run
`[2016-09-18T00:00:00.000Z TO 2016-09-20T23:59:59.999Z]` and include dates like
`2016-09-20T15:32:44`. This behaviour was lost in the cleanups of #8889.

Closes #20579
jpountz added a commit that referenced this issue Oct 7, 2016
Elasticsearch 1.x used to implicitly round up upper bounds of queries when they
were inclusive so that eg. `[2016-09-18 TO 2016-09-20]` would actually run
`[2016-09-18T00:00:00.000Z TO 2016-09-20T23:59:59.999Z]` and include dates like
`2016-09-20T15:32:44`. This behaviour was lost in the cleanups of #8889.

Closes #20579
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants