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

Support Hive's TIMESTAMP WITH LOCAL TIME ZONE #1240

Closed
findepi opened this issue Aug 2, 2019 · 6 comments · Fixed by #13595
Closed

Support Hive's TIMESTAMP WITH LOCAL TIME ZONE #1240

findepi opened this issue Aug 2, 2019 · 6 comments · Fixed by #13595

Comments

@findepi
Copy link
Member

findepi commented Aug 2, 2019

Hive 3.1 adds a new data type: TIMESTAMP WITH LOCAL TIME ZONE.

Example:

beeline> create table x(t timestamp, tltz timestamp with local time zone);
OK

beeline> desc x;
+-----------+---------------------------------------------------+----------+
| col_name  |                     data_type                     | comment  |
+-----------+---------------------------------------------------+----------+
| t         | timestamp                                         |          |
| tltz      | timestamp with local time zone('Asia/Kathmandu')  |          |
+-----------+---------------------------------------------------+----------+
presto:default> desc x;
 Column |   Type    | Extra | Comment
--------+-----------+-------+---------
 t      | timestamp |       |
(1 row)

Add support for this type in Hive connector.

@findepi findepi mentioned this issue Aug 2, 2019
29 tasks
@dain
Copy link
Member

dain commented Aug 14, 2020

We should map this to TIMESTAMP WITH TIME ZONE

@findepi
Copy link
Member Author

findepi commented Oct 20, 2021

"timestamp with local time zone" suggests mapping into session zone,
but that leads to #5781
of course, mapping to UTC is not what Hive is doing.

@martint
Copy link
Member

martint commented Apr 26, 2023

I agree that we should map this to TIMESTAMP WITH TIME ZONE with a fixed timezone that is insensitive to daylight savings or other adjustments that lead to ambiguities (i.e., practically speaking, UTC). This is the best we can do to provide interoperability with Hive for this type. The alternative is not to support it at all, which means many Hive users cannot easily switch to Trino or query their data.

@findepi
Copy link
Member Author

findepi commented Apr 27, 2023

if we had "instant" type (#2273) we could map to that.

@martint
Copy link
Member

martint commented Apr 27, 2023

But we don't, and it's not clear that Trino needs such a type or how that type would interoperate with other datetime types and datetime functions.

@mosabua
Copy link
Member

mosabua commented May 3, 2023

In order to solve this problem I suggest we review this PR and merge it with the current proposed approach to unblock existing users. If we ever end up creating an instant type we can reconsider and change.

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

Successfully merging a pull request may close this issue.

4 participants