测试数据准备

首先，我们将测试集群的impala的use_local_tz_for_unix_timestamp_conversions和convert_legacy_hive_parquet_utc_timestamps参数都配置为false，然后重启集群。 接着，我们使用如下SQL来创建测试表，然后插入数据：

create table timestamp_test_parquet(id int,ts timestamp,sec bigint) stored as parquet;insert into timestamp_test_parquet values(1001,UTC_TIMESTAMP(),cast(UTC_TIMESTAMP() as bigint));

这里，为了保证一致，我们特地插入了UTC的时间，然后查询表，可以看到如下的结果：

我们执行date -d @1596003620 "+%Y-%m-%d %H:%M:%S"命令，可以得到：2020-07-29 06:20:20，现在这2个时间都是UTC的时间没问题。如果是本地时间的话，应该是2020-07-29 14:20:20（当前笔者所处的时区为东八区，即UTC+8，后面默认本地时区都是UTC+8）。

参数开启前后对比

为了验证参数里面提到的timestamp->bigint/bigint->timestamp这个转换操作，我们分别关闭/开启参数，重启集群保证参数生效，然后执行如下SQL：

select id,cast(ts as bigint),cast(sec as timestamp) from timestamp_test_parquet;

以下是两次SQL执行的结果，我们合并到了一起进行对比：

通过上述结果，我们发现，参数开启前后，两次SQL的执行结果明显是不同的。接下来，我们来根据结果进行仔细分析。

cast(ts as bigint)

当我们将timestamp转换为bigint的时候，前后两次的结果分别是：1596003620和1595974820，我们通过date命令进行转换，结果如下：

我们发现参数开启后，得到的bigint值比开启前的少了8h！这个地方要如何理解呢？结合官方的解释： 参数开启之后，会将timestamp当成是本地时区的时间。所以，当我们开启参数之后，2020-07-29 06:20:20这个时间就被当成了是UTC+8的时间（默认是UTC的时间），因此在cast成bigint的时候，会把它转换成UTC的时间，所以需要减掉8h，就变成了2020-07-28 22:20:20，也就是1595974820。

cast(sec as timestamp)

当我们将bigint转换成timestamp的时候，前后2次的结果分别是：2020-07-29 06:20:20和2020-07-29 14:20:20，这里参数开启后，得到的值比开启前的多了8h！同样的道理，当参数开启之后，sec存储的是UTC的时间对应的bigint，即2020-07-29 06:20:20，所以转换成UTC+8之后，就变成了2020-07-29 14:20:20