同事在开发过程中遇到了时区问题，经过同事们的努力问题最终解决了。这让我发现时区接口比我想像的要复杂一些。
首先，时间如果是一个物理概念，那么它跟空间是无关的。例如经典的 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 时间戳。
