本文为您介绍如何配置MaxCompute Project的时区。

时区配置的方式

MaxCompute Project时区默认是中国的东八区,DATETIME、TIMESTAMP、DATE类型字段以及相关时间内置函数都是按东八区进行计算。您可以通过以下两种方式进行时区的配置:
  • Session级别:set odps.sql.timezone=<timezoneid>;语句需要与计算语句一起提交。
    set odps.sql.timezone=Asia/Tokyo;
    select getdate();
    --结果如下。
    output:
    +------------+
    | _c0        |
    +------------+
    | 2018-10-30 23:49:50 |
    +------------+
  • Project级别:Project Owner需要执行setProject odps.sql.timezone=<timezoneid>;语句。Project的时区一旦被设置,对应相关的时间计算会取设置后的时区,原有的任务数据将会受到影响。所以,请您谨慎考虑是否有必要设置时区。如果必要,建议只对新增的Project进行设置,不建议对已有数据的Project进行设置。

使用限制及注意事项

  • 时区配置支持的范围:SQL内置日期函数、UDF、UDT、UDJ、select transform都支持获取Project Timezone属性来支持时区。
  • 时区支持的格式为Asia/Shanghai这类格式(存在夏令时跳变),不支持GMT+9格式。
  • 当SDK时区与Project时区不同时,DATETIME->STRING操作需设置GMT时区。
  • 时区配置后,通过DataWorks执行相关SQL时,日期显示某些时间段会存在时间差异,例如1900~1928年的日期时间差异为5分52秒,1900年之前的日期时间差异为9秒。
  • 为了保证MaxCompute在多个时区DATETIME类型数据的正确性,MaxCompute服务、Java SDK以及配套的Console将在近期进行版本更新(-oversea后缀的Java SDK/Console版本),更新后可能影响MaxCompute中已经存储的早于1928年的DATETIME类型数据的显示。
  • 对于非中国东八区的区域,建议您同步更新Java SDK/Console版本,以保证SQL计算结果及Tunnel传输1900-01-01之后范围的数据的准确性和一致性。对于早于1900-01-01的DATETIME数据,SQL的计算显示结果和Tunnel传输数据仍然可能存在343秒的差异。对于新版本SDK/Console之前已经上传的早于1928-01-01的DATETIME数据,在新版本中日期时间会减少352秒。
  • 如果继续使用不带有-oversea后缀的SDK/Console,SQL计算结果和Tunnel传输数据将存在差异。早于1900-01-01的数据差异为9秒,1900-01-01~1928-01-01的数据差异为352秒。
    说明 Java SDK/Console版本更新配置时区不影响DataWorks的时区配置,因此时区会存在差异,需要您对DataWorks中定时任务调度的影响进行计算评估。DataWorks服务器在日本Region的时区是GMT+9,在新加坡Region的时区是GMT+8。
  • 通过JDBC连接的第三方客户端需要在客户端设置时区,保证与服务端时区设置的一致性。
  • MapReduce支持时区功能。
  • Spark支持时区功能。
    • 对于提交到MaxCompute计算集群的任务形式,可自动获取Project的时区。
    • 对于通过yarn-client模式启动(例如spark-shell,spark-sql,pyspark等)的设置,您需要手动配置Driver的启动参数(spark-defaults.conf),增加spark.driver.extraJavaOptions -Duser.timezone=America/Los_Angelestimezone的值为将要使用的时区。
  • PAI支持时区功能。
  • Graph支持时区功能。