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

SQL: Custom timezone is not used in CAST/CONVERT #40692

Open
matriv opened this issue Apr 1, 2019 · 8 comments
Open

SQL: Custom timezone is not used in CAST/CONVERT #40692

matriv opened this issue Apr 1, 2019 · 8 comments
Labels
:Analytics/SQL SQL querying >bug Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo)

Comments

@matriv
Copy link
Contributor

matriv commented Apr 1, 2019

SELECT CAST('2019-01-14T12:29:25.000+05:00' AS DATETIME) returns
2019-01-14T12:29:25.000Z` instead of `+05:00

Also the whole CASTING/ESCAPE literals should be revisited as UTC is always used.
So if the client uses a custom timezone and uses a filter like: SELECT * FROM t WHERE created = CAST('2019-01-14T12:29:25.000' AS DATETIME) the date literal will be in UTC which I think is not what the client would expect.

Also simple SELECT CAST('2019-01-14T12:29:25.000' AS DATETIME) should convert it to the timezone set by the client and not UTC.

@matriv matriv added >bug :Analytics/SQL SQL querying labels Apr 1, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search

@matriv
Copy link
Contributor Author

matriv commented Apr 1, 2019

@costin @astefan Please share your opinion for the 2nd part of the bug (as the 1st seems straightforward?)

@astefan
Copy link
Contributor

astefan commented Apr 2, 2019

@matriv I am not convinced about the first part. I've tested PostgreSQL and the timezone is not outputted for something like SELECT CAST('2019-02-14T12:29:25.000+07:00' AS TIMESTAMP);. But I kinda agree on the second part.

@matriv
Copy link
Contributor Author

matriv commented Apr 2, 2019

@astefan But you cast a well defined timestamp at a custom timezone and you get back the same exact timestamp but with indication UTC.

@matriv
Copy link
Contributor Author

matriv commented Mar 30, 2020

@elastic/es-ql

@rjernst rjernst added the Team:QL (Deprecated) Meta label for query languages team label May 4, 2020
@Luegg
Copy link
Contributor

Luegg commented Aug 13, 2021

Looks like the bug has been resolved in the meantime. I cannot reproduce it on 7.14.0 anymore:

SELECT CAST('2019-02-14T00:00:00.000+05:00' AS TIMESTAMP) ts

           ts
------------------------
2019-02-13T19:00:00.000Z

So the timezone has been considered but the result is still presented in UTC and not in the time zone provided with the time_zone parameter.

@Luegg
Copy link
Contributor

Luegg commented Aug 13, 2021

The second part is still present though:

curl --silent --show-error --include -H 'Content-Type: application/json' \
-X POST 'http://localhost:9201/_sql?format=txt' \
-d '{"query": "select '\''1987-09-21T00:00:00'\''::datetime dt", "time_zone":"+05:00"}'

           dt
------------------------
1987-09-21T00:00:00.000Z

But the output should probably be equivalent to specifying the time zone in the query:

curl --silent --show-error --include -H 'Content-Type: application/json' \
-X POST 'http://localhost:9201/_sql?format=txt' \
-d '{"query": "select '\''1987-09-21T00:00:00+05:00'\''::datetime dt"}'

           dt
------------------------
1987-09-20T19:00:00.000Z

Luegg pushed a commit to Luegg/elasticsearch that referenced this issue Aug 18, 2021
@wchaparro wchaparro removed the Team:QL (Deprecated) Meta label for query languages team label Jan 17, 2024
@elasticsearchmachine elasticsearchmachine added the Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) label Jan 17, 2024
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-analytical-engine (Team:Analytics)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Analytics/SQL SQL querying >bug Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants