[ 
https://issues.apache.org/jira/browse/FLINK-32689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17747559#comment-17747559
 ] 

Timo Walther commented on FLINK-32689:
--------------------------------------

Update: I could confirm it with this program
{code}
        final StreamExecutionEnvironment env = 
StreamExecutionEnvironment.getExecutionEnvironment();
        final StreamTableEnvironment tableEnv = 
StreamTableEnvironment.create(env);

        DataStream<Row> row = 
env.fromElements(Row.of(Instant.now().toEpochMilli()));
        tableEnv.createTemporaryView("t", row);

        tableEnv.getConfig().set(TableConfigOptions.LOCAL_TIME_ZONE, "UT-10");

        tableEnv.executeSql("SELECT TO_TIMESTAMP_LTZ(f0, 3) FROM t").print();
{code}

Will prepare a fix.

> Insufficient validation for table.local-time-zone
> -------------------------------------------------
>
>                 Key: FLINK-32689
>                 URL: https://issues.apache.org/jira/browse/FLINK-32689
>             Project: Flink
>          Issue Type: Bug
>          Components: Table SQL / API
>            Reporter: Timo Walther
>            Assignee: Timo Walther
>            Priority: Major
>
> There are still cases where timezone information is lost silently due to the 
> interaction between {{java.util.TimeZone}} and {{java.time.ZoneId}}.
> This might be theoretical problem, but I would feel safer if we change the 
> check to:
> {code}
> if 
> (!java.util.TimeZone.getTimeZone(zoneId).toZoneId().equals(ZoneId.of(zoneId)))
>  {
>    throw new ValidationException(errorMessage);
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to