[
https://issues.apache.org/jira/browse/CALCITE-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L closed CALCITE-5977.
------------------------------
Resolution: Not A Problem
> 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)
