[ 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)