Re: debezium-json数据timestamp类型时区问题

2022-11-24 文章 Leonard Xu
你在Oracle 数据库中的数据类型是TIMESTAMP 还是 TIMESTAMP WITH LOCAL TIME ZONE? 
我猜是后者,如果是后者直接在Flink SQL 里TIMESTAMP_LTZ 类型去映射就可以了
Oracle 的TIMESTAMP LTZ 类型和Flink SQL的TIMESTAMP LTZ类型含义和存储都是一致的语义,即epoch 
mills,存储时不需要时区。这两个类型都是在各自的系统中在在需要查看这些数据时,需要用 session 时区从epoch mills 
转换成可读timestamp格式的字符串。

Oracle 设置session 时区的命令是:
ALTER SESSION SET TIME_ZONE='Asia/Shanghai';

Flink SQL 设置session 时区的命令是:
Flink SQL> SET 'table.local-time-zone' = 'Asia/Shanghai';

祝好,
Leonard


> On Nov 22, 2022, at 4:32 PM, Kyle Zhang  wrote:
> 
> Hi all,
>我们有一个场景,是把oracle数据通过debezium-oracle-cdc插件抽到kafka中,后面接flink
> sql分析,现在遇到一个时区的问题,比如数据库中有一个timestamp类型的字段,值是‘2022-11-17
> 16:16:44’,但是debezium处理的时候用了int64保存,还不带时区信息,变成1668701804000,导致flink
> sql中用FROM_UNIXTIME处理后变成‘2022-11-18 00:16:44
> ’,差了8小时,需要手工再减8h。请问有没有一种统一的方式处理这种情况?
> 
> Best



debezium-json数据timestamp类型时区问题

2022-11-22 文章 Kyle Zhang
Hi all,
我们有一个场景,是把oracle数据通过debezium-oracle-cdc插件抽到kafka中,后面接flink
sql分析,现在遇到一个时区的问题,比如数据库中有一个timestamp类型的字段,值是‘2022-11-17
16:16:44’,但是debezium处理的时候用了int64保存,还不带时区信息,变成1668701804000,导致flink
sql中用FROM_UNIXTIME处理后变成‘2022-11-18 00:16:44
’,差了8小时,需要手工再减8h。请问有没有一种统一的方式处理这种情况?

Best