本文为您介绍如何使用SET命令配置MaxCompute Project的时区。
支持时区功能的作业如下：
- MapReduce支持时区功能。
- Spark支持时区功能。
- PAI支持时区功能。
- Graph支持时区功能。
配置时区
MaxCompute Project时区默认是中国的东八区，DATETIME、TIMESTAMP、DATE类型字段以及相关时间内置函数按照东八区进行计算。您可以通过以下两种方式配置时区：
- Session级别：执行
SET odps.sql.timezone=;语句，需要与计算语句一起提交。--设置时区为Asia/Tokyo。 SET odps.sql.timezone=Asia/Tokyo; --查询当前时区。 SELECT getdate(); output: +------------+ | _c0 | +------------+ | 2018-10-30 23:49:50 | +------------+ - Project级别：执行
setproject odps.sql.timezone=;语句，此命令需要项目所有者（Project Owner）执行。
注意 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以及客户端将会进行版本更新（-oversea后缀的Java SDK或客户端版本），更新后可能影响MaxCompute中已经存储的早于1928年的DATETIME类型数据的显示。
- 对于非中国东八区的区域，建议您同步更新Java SDK或客户端版本，以保证在1900-01-01之后的SQL计算结果及Tunnel传输数据的准确性和一致性。对于早于1900-01-01的DATETIME数据，SQL的计算显示结果和Tunnel传输数据仍然可能存在343秒的差异。对于新版本SDK或客户端，之前已经上传的早于1928-01-01的DATETIME数据，在新版本中日期时间会减少352秒。
- 如果继续使用不带有-oversea后缀的SDK或客户端，SQL计算结果和Tunnel传输数据将存在差异。早于1900-01-01的数据差异为9秒，1900-01-01~1928-01-01的数据差异为352秒。
说明 Java SDK或客户端版本更新配置时区不影响DataWorks的时区配置，因此时区会存在差异，需要您对DataWorks中定时任务调度的影响进行计算评估。DataWorks服务器在日本区域的时区是GMT+9，在新加坡Region的时区是GMT+8。 - 通过JDBC连接的第三方客户端需要在客户端设置时区，保证与服务端时区设置的一致性。
内容没看懂？ 不太想学习？想快速解决？ 有偿解决： 联系专家
阿里云企业补贴进行中： 马上申请
腾讯云限时活动1折起，即将结束： 马上收藏
同尘科技为腾讯云授权服务中心。
购买腾讯云产品享受折上折，更有现金返利:同意关联，立享优惠
转转请注明出处：https://www.yunxiaoer.com/158364.html
