presto332升级presto350时，kudu时间戳少了8小时问题

一，问题现象

    原业务使用presto332写入和查询kudu。业务想将presto332升级到presto350，发现350查询 332插入的时间戳字段 少了8个小时。350查询 350插入的时间戳字段 是正常的。

二，问题分析

    1，时间戳的解析可以理解为 有两个字段决定，long类型的时间值和时区。下文以时间戳1675306586为例进行分析，1675306586 和 北京时区，解析出来就是 2023-03-02 10:56:26。 而1675306586 和 UTC时区，解析出来就是 2023-03-02 02:56:26

    2，查看kudu中时间戳实际存储的long类型的数据，350写入的值是1675335386，332写入的值是1675306586。350写入的 比332写入的 多了8小时。 所以推论出presto350在解析时间戳的时候，将 kudu中的long类型时间值 ➕ UTC时区进行解析。 而332版本是，将 kudu中的long类型时间值 ➕ 北京时区进行解析。 所以就会造成 350查询 332插入的时间戳字段 少了8个小时。350查询 350插入的时间戳字段 是正常的。

三，问题解决，尚未找到较好的解决方案。

四，以下面的语句为例，观察presto350的处理流程 

        INSERT INTO kudu.default.changchang_test1 VALUES (1, current_timestamp); 

     1，查看逻辑计划，时间戳的处理在Fragment 2阶段。

  2，插入语句中，时间戳函数的 大概处理流程如下：

           2.1，cordinator，执行current_timestamp函数得到时间戳， LogicalPlanner.plan -> IterativeOptimizer.optimize  →    ExpressionRewriteRuleSet$ValuesExpressionRewrite.rewrite → visitFunctionCall → CurrentTimestamp.shortTimestamp

           2.2，cordinator，将long类型时间戳转成string，即2023-03-02 10:56:26.512，主要过程LogicalPlanner.plan -> IterativeOptimizer.optimize -> ExpressionRewriteRuleSet$ValuesExpressionRewrite.rewrite -> LiteralEncoder.toExpression

           2.3，worker，将string转成long类型时间戳，localPlaner -> visitValues -> ExpressionAnalyzer -> DateTimes.parseTimestampWithTimeZone

           2.4，worker，driver执行，driverSplit -> operator -> TimestampWithTimeZoneToTimestampCast.shortToShort 这里会将时间戳加8小时，即1675306586 + 8小时 = 1675335386。

    3，写入时，presto332和presto350的主要不同之处在于2.4步骤上，350加了8小时，而332没有加。 

    4，350读取时，返回SqlTimestamp，ShortTimestampType.getObjectValue 构造SqlTimestamp对象没有时区信息，所以使用的是默认的UTC时区。

 332读取时，返回SqlTimestamp，ShortTimestampType.getObjectValue 构造SqlTimestamp对象，使用的北京时区。