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

[0.9.3] invalid timestamp format should throw parser error, not be ignored #3932

Closed
beckettsean opened this issue Sep 1, 2015 · 3 comments
Closed

Comments

@beckettsean
Copy link
Contributor

When giving explicit timestamps in queries they must be single-quoted:

> select count(value) from cpu_idle where time >= '2015-08-25T20:00:00Z' and time <= '2015-08-25T21:00:00Z'  group by time(10m)
name: cpu_idle
--------------
time            count
2015-08-25T20:00:00Z    8
2015-08-25T20:10:00Z    144
2015-08-25T20:20:00Z    688
2015-08-25T20:30:00Z    688
2015-08-25T20:40:00Z    688
2015-08-25T20:50:00Z    680
2015-08-25T21:00:00Z    688

Double-quoting returns results as if there were no time restriction at all:

> select count(value) from cpu_idle where time > "2015-08-25T20:00:00Z" and time < "2015-08-25T21:00:00Z"  group by time(10m)
name: cpu_idle
--------------
time            count
1970-01-01T00:00:00Z    618464

> select count(value) from cpu_idle
name: cpu_idle
--------------
time            count
1970-01-01T00:00:00Z    618464
@corylanou
Copy link
Contributor

We should specifically return an error if we detected a literal (double quotes instead of single) and error with something like time literals need to be single quoted, not double quoted.

@beckettsean
Copy link
Contributor Author

Per Paul, in a WHERE time clause, first try to parse the double-quoted value as a timestamp, not an identifier. If that fails fall back to parsing it as an identifier.

@beckettsean beckettsean added this to the Future Point Release milestone Sep 8, 2015
@jsternberg jsternberg self-assigned this Mar 16, 2016
@jsternberg
Copy link
Contributor

The reason for this problem is because the function that retrieves the time range doesn't send back an error when it finds an objectionable time comparison like was done here.

The function that needs to be changed is influxql.TimeRange(). I can probably do this one with #3290.

jsternberg added a commit that referenced this issue Mar 28, 2016
A bigger refactor of these functions is needed to support #3290, but
this will work for the more common case that someone uses double quotes
instead of single quotes when surrounding a time literal.

Fixes #3932.
benbjohnson pushed a commit that referenced this issue Mar 31, 2016
A bigger refactor of these functions is needed to support #3290, but
this will work for the more common case that someone uses double quotes
instead of single quotes when surrounding a time literal.

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

No branches or pull requests

3 participants