本文为您介绍如何使用SET命令配置MaxCompute Project的时区。
支持时区功能的作业如下：
MapReduce支持时区功能。
Spark支持时区功能。
对于提交到MaxCompute计算集群的任务，可自动获取Project的时区。
对于通过yarn-client模式启动（例如spark-shell，spark-sql，pyspark等）的设置，您需要手动配置Driver的启动参数（spark-defaults.conf），增加
spark.driver.extraJavaOptions -Duser.timezone=America/Los_Angeles，timezone的值为将要使用的时区。
PAI支持时区功能。
Graph支持时区功能。
配置时区
MaxCompute Project时区默认是中国的东八区，DATETIME、TIMESTAMP、DATE类型字段以及相关时间内置函数按照东八区进行计算。您可以通过以下两种方式配置时区：
Session级别：执行
SET odps.sql.timezone=<timezoneid>;语句，需要与计算语句一起提交。--设置时区为Asia/Tokyo。 SET odps.sql.timezone=Asia/Tokyo; --查询当前时区。 SELECT getdate(); output: +------------+ | _c0 | +------------+ | 2018-10-30 23:49:50 | +------------+Project级别：执行
setproject odps.sql.timezone=<timezoneid>;语句，此命令需要项目所有者（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连接的第三方客户端需要在客户端设置时区，保证与服务端时区设置的一致性。