[
https://issues.apache.org/jira/browse/CALCITE-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762129#comment-17762129
]
Ruben Q L commented on CALCITE-5977:
------------------------------------
Thanks for the feedback [~julianhyde].
But then, if I am not mistaken, that would mean that if we run these two
queries in Calcite:
{code:sql}
SELECT * FROM myTable t WHERE t.lastUpdate > TIMESTAMP'2023-08-28 09:56:54'
SELECT * FROM myTable t WHERE t.lastUpdate > TIMESTAMP WITH LOCAL TIME
ZONE'2023-08-28 09:56:54'
{code}
The dynamic code that will be generated to produce the query result with
Enumerable convention will be exactly the same, right? Is that correct?
> RexLiteral returns the same value for TIMESTAMP and
> TIMESTAMP_WITH_LOCAL_TIME_ZONE
> ----------------------------------------------------------------------------------
>
> Key: CALCITE-5977
> URL: https://issues.apache.org/jira/browse/CALCITE-5977
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Ruben Q L
> Priority: Major
>
> Perhaps I'm missing something, but this seems odd to me.
> If we want to get the value in Long format (i.e. milliseconds since
> 1970-01-01 00:00:00) of a TIMESTAMP / TIMESTAMP_WITH_LOCAL_TIME_ZONE
> RexLiteral, their code is exactly the same (even if they are in different
> "case" blocks):
> {code}
> public @Nullable Object getValue2() {
> ...
> switch (typeName) {
> ...
> case TIMESTAMP:
> case TIMESTAMP_WITH_LOCAL_TIME_ZONE:
> return getValueAs(Long.class);
> ...
> }
> public <T> @Nullable T getValueAs(Class<T> clazz) {
> ...
> switch (typeName) {
> ...
> case TIMESTAMP:
> if (clazz == Long.class) {
> // Milliseconds since 1970-01-01 00:00:00
> return clazz.cast(((TimestampString) value).getMillisSinceEpoch());
> }
> ...
> break;
> case TIMESTAMP_WITH_LOCAL_TIME_ZONE:
> if (clazz == Long.class) {
> // Milliseconds since 1970-01-01 00:00:00
> return clazz.cast(((TimestampString) value).getMillisSinceEpoch());
> }
> ...
> {code}
> In case of a TIMESTAMP_WITH_LOCAL_TIME_ZONE, shouldn't this code include some
> extra processing to "shift" the value with the proper offset / daylight
> savings?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
