You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My time zone is CST, not UTC. Based on some best practices of ES, when we store data, we convert CST time to UTC time for storage, and the corresponding conversion is done by time zone when querying.
When I was using superset, I found two problems
elasticsearch-dbapi does not support passing the time_zone parameter, I tried to fix it and submitted a PR feat(query): add time_zone param preset-io/elasticsearch-dbapi#69, currently waiting for a review, but I can fix it temporarily by pip install <my_github_repo>. It's equivalent to hitting a patch to circumvent the issue.
returnf"""CAST('{dttm.isoformat(timespec="seconds")}' AS DATETIME)"""
returnNone
time_zone on CAST this way of conversion does not work, only date related functions work, to solve this problem, should use DATETIME_PARSE ('date', '{pattern}') to deal with, time_zone on this function works.
Here are some examples of my steps to demonstrate this in kibana
PUT /library/_bulk?refresh
{"index":{"_id": "Leviathan Wakes"}}
{"name": "Leviathan Wakes", "author": "James S.A. Corey", "release_date": "2021-09-17T13:24:19Z", "page_count": 561}
{"index":{"_id": "Hyperion"}}
{"name": "Hyperion", "author": "Dan Simmons", "release_date": "2021-09-17T19:24:19Z", "page_count": 482}
{"index":{"_id": "Dune"}}
{"name": "Dune", "author": "Frank Herbert", "release_date": "2021-09-18T09:24:19Z", "page_count": 604}
# UTC -> CST# 2021-09-17T13:24:19Z => 2021-09-17T21:24:19+08:00# 2021-09-17T19:24:19Z => 2021-09-18T03:24:19+08:00# 2021-09-18T09:24:19Z => 2021-09-18T17:24:19+08:00# should be return 2 ,but 1, **because time_zone does not work for CAST**GET /_sql?format=txt
{
"query": """SELECT * FROM "library" where release_date > CAST('2021-09-17T21:24:19' AS DATETIME)""","time_zone": "Asia/Shanghai"
}
author | name | page_count | release_date ---------------+---------------+---------------+-----------------------------Frank Herbert |Dune |604 |2021-09-18T17:24:19.000+08:00## return 2, work!!GET /_sql?format=txt
{
"query": """SELECT * FROM "library" where release_date > DATETIME_PARSE('2021-09-17 21:24:19', 'yyyy-MM-dd HH:mm:ss')""","time_zone": "Asia/Shanghai"
}
author | name | page_count | release_date ---------------+---------------+---------------+-----------------------------Dan Simmons |Hyperion |482 |2021-09-18T03:24:19.000+08:00Frank Herbert |Dune |604 |2021-09-18T17:24:19.000+08:00
The above example should have illustrated the problem, the essence is that CAST this way for the time zone settings do not take effect, this is important for non-UTC users, I think we need to solve it, at present I can think of is
change to DATETIME_PARSE, but there is no such function before ES 7.8.
superset database add global time_zone parameter, the datetime object for filtering should carry the corresponding time zone information, and the format should also carry the time zone information. This way I found by looking at the code that the scope is too wide and will affect other data sources.
If we have to be compatible with users before ES7.8, a compromise solution is to create a separate db_engine_spec for ES7.8 and above, which can be implemented in elasticsearch-dbapi as a separate sqlalchemy ESDialect, the name of which may require some careful thought.
My time zone is CST, not UTC. Based on some best practices of ES, when we store data, we convert CST time to UTC time for storage, and the corresponding conversion is done by time zone when querying.
When I was using superset, I found two problems
time_zone
parameter, I tried to fix it and submitted a PR feat(query): add time_zone param preset-io/elasticsearch-dbapi#69, currently waiting for a review, but I can fix it temporarily by pip install <my_github_repo>. It's equivalent to hitting a patch to circumvent the issue.datetime type fields
, but it worked forHISTOGRAM("@timestamp", INTERVAL 1 DAY)
, I found the reason by checking the ES-SQL documentation, https://www.elastic.co/guide/en/elasticsearch/reference/current/sql-search-api.html#sql-search-api-request-bodySeveral SQL date/time functions use this time zone very important!
superset on ES datatime field query, is the use of
CAST ('date' AS DATETIME)
,superset/superset/db_engine_specs/elasticsearch.py
Lines 62 to 65 in cc1c6c1
time_zone on
CAST
this way of conversion does not work, only date related functions work, to solve this problem, should useDATETIME_PARSE ('date', '{pattern}')
to deal with, time_zone on this function works.Here are some examples of my steps to demonstrate this in kibana
The above example should have illustrated the problem, the essence is that CAST this way for the time zone settings do not take effect, this is important for non-UTC users, I think we need to solve it, at present I can think of is
If we have to be compatible with users before ES7.8, a compromise solution is to create a separate db_engine_spec for ES7.8 and above, which can be implemented in
elasticsearch-dbapi
as a separatesqlalchemy ESDialect
, the name of which may require some careful thought.new db_engine_spec
This is the solution I have thought of so far, what do you think?
cc @dpgaspar
The text was updated successfully, but these errors were encountered: