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
Presto doesn't understand ISO 8601 timestamp strings as time-like, so currently, timestamp comparisons in Presto are being executed as lexical varchar comparisons.
This means that TIMESTAMP columns in Presto can't be used as dttm columns. If you do try to use a TIMESTAMP column in Presto as a dttm column, you get a GREATER_THAN_OR_EQUAL(timestamp, varchar) not registered
One solution would be to add a Presto-specific dttm_converter, such as
"CAST('{}' AS TIMESTAMP)".format(dttm.strftime('%Y-%m-%d %H:%M:%S.%f')[:-3]))
This approach was initially proposed in #522, but I'm creating this issue so that we can discuss more broadly. #506 (or a per-column version) is necessary but not sufficient - if & when it it gets merged, the timestamp comparison with still be performed as a lexical string comparisons in Presto, and that is not going to work for date formats such as MM/DD/YYYY. (e.g. 01/01/2001 < 02/01/2000).
Whatever solution we end up with should not hinder Presto's optimizer from partition pruning and index utilization.
The text was updated successfully, but these errors were encountered:
Presto doesn't understand ISO 8601 timestamp strings as time-like, so currently, timestamp comparisons in Presto are being executed as lexical varchar comparisons.
This means that
TIMESTAMP
columns in Presto can't be used as dttm columns. If you do try to use aTIMESTAMP
column in Presto as a dttm column, you get aGREATER_THAN_OR_EQUAL(timestamp, varchar) not registered
One solution would be to add a Presto-specific dttm_converter, such as
This approach was initially proposed in #522, but I'm creating this issue so that we can discuss more broadly.
#506 (or a per-column version) is necessary but not sufficient - if & when it it gets merged, the timestamp comparison with still be performed as a lexical string comparisons in Presto, and that is not going to work for date formats such as MM/DD/YYYY. (e.g. 01/01/2001 < 02/01/2000).
Whatever solution we end up with should not hinder Presto's optimizer from partition pruning and index utilization.
The text was updated successfully, but these errors were encountered: