[CALCITE-7491] Literals of type TIMESTAMP WITH TIME ZONE cause crashes#4910
[CALCITE-7491] Literals of type TIMESTAMP WITH TIME ZONE cause crashes#4910mihaibudiu merged 1 commit intoapache:mainfrom
Conversation
|
|
||
| # Test case for [CALCITE-7491] https://issues.apache.org/jira/browse/CALCITE-7491 | ||
| # Literals of type TIMESTAMP WITH TIME ZONE cause crashes | ||
| # TODO: thie result should probably be displayed using time-zone |
There was a problem hiding this comment.
Nit: We generally don't add TODOs, it's preferable to file a ticket for Avatica and cite it here IMO
asolimando
left a comment
There was a problem hiding this comment.
LGTM, temporal data types, especially with time zones, are always a headache, thanks for fixing this!
|
I have addressed @asolimando's comments, but I will wait a bit to see whether there are other comments. |
| !ok | ||
|
|
||
| # Two timestamps with time zone are equal if they represent the same UTC time | ||
| SELECT TIMESTAMP WITH TIME ZONE '2020-01-01 08:10:10 America/New_York' = TIMESTAMP WITH TIME ZONE '2020-01-01 05:10:10 America/Los_Angeles'; |
There was a problem hiding this comment.
Can we add a field here that returns false for the same time but different time zones?
There was a problem hiding this comment.
We can, but I was planning to leave more complex tests for TIMESTAMP WITH TIME ZONE for a separate PR, including arithmetic, functions, etc.
I will add this one here, since it's similar.
There was a problem hiding this comment.
If you have this plan, then you don't need to add it; you can supplement it with more comprehensive testing in the new PR.
There was a problem hiding this comment.
See last commit.
Signed-off-by: Mihai Budiu <mbudiu@feldera.com>
|



Jira Link
https://issues.apache.org/jira/browse/CALCITE-7491
Changes Proposed
Fixes bugs that prevented the runtime from instantiating
TIMESTAMP WITH TIME ZONEliteral values.Also, fixes defines two
TIMESTAMP WITH TIME ZONEto be equal when they represent the same UTC timestamp.