时区问题 - Python 为例

同事在开发过程中遇到了时区问题，经过同事们的努力问题最终解决了。这让我发现时区接口比我想像的要复杂一些。

首先，时间如果是一个物理概念，那么它跟空间是无关的。例如经典的 POSIX 时间戳，以 Epoch 为起点记录时间差。Epoch 是一个物理时间，全球都代表同一个意思，那么这种计时方法就是跟空间无关的。

然而因为地球是个球形，全球对「14 点」这类感受是不一致的。在美国的 14 点代表的物理时间，地球上其他地方可能是晚上，要求这些地方用 14 点表示一个晚上的时间，他们必然不会舒服。这就是划分时区的意义。

当我说 2009 年 12 月 23 日 12 点的时候，这个表述严格来说不能完全表示一个物理时间。日本的 2009 年 12 月 23 日 12 点和中国的 2009 年 12 月 23 日 12 点是不一样的物理时间。所以我应该说「 2009 年 12 月 23 日 12 点，UTC+8」后面的 UTC+8 表示这个时间比 UTC 时间多 8 个小时，也就是说是中国时间。

「 2009 年 12 月 23 日 12 点，UTC+8」和 「 2009 年 12 月 23 日 4 点，UTC」是同一个时间吗？从时区时间来看，是不一样的；从物理时间来看，是一样的。

但是如果我们一直生活在同一个时区，这也是我们大多数人的体验，表示时间的描述里对时区的描述就显得很多余，这时我们习惯于省略时区的表述。

Python 的 datetime 文档 表示，datetime 类别，有两种实例，一种是「aware」的，一种是「naive」的。即前一种包含了时区信息，后一种省略了时区信息。举例几个接口：

• datetime.now(tz=None)

  获取当地时间，当 tz 是 None 返回的是 naive 的，否则是 aware 的。

• datetime.utctime()

  把当地时间转换成 UTC 时区的时间，但是得到的 datetime 是 naive 的。

• datetime.timestamp(self)

  计算当前时间（如果是 naive 的，看作是当地时间）的 Unix 时间戳。得到一个距离 Epoch 的时间长度的浮点数描述。

从上面的描述可以看出，datetime.utcnow().timestamp() 得到的是一个奇怪的值，几乎没有任何意义。

Python 的文档也建议，如果要取 UTC 时间，应该使用 datetime.now(timezone.utc)，这样就可以得到 aware 的 UTC 时间。它的 timestamp() 方法，就可以得出正确的 Unix 时间戳。