声明
本文章只针对python3.6及以上版本。
问题提出
首先，我们先import一些必要模块：
In [1]:fromdatetimeimportdatetime, timezone, timedelta
接下来，看下面这一段令人疑惑的代码：
首先，我们知道，在计算机中，时间实际上是用数字表示的。我们把1970年1月1日 00:00:00 UTC+00:00时区的时刻称为epoch time，记为0（1970年以前的时间timestamp为负数），当前时间就是相对于epoch time的秒数，称为timestamp。
这里，我构建了一个“1970年1月1日 00:00:00”的时间，按照理解，这个时间的timestamp应该是0.但从输出可以看到，出现了OSError错误。
经过一点点探索，我发现，能够以上面方式输出timestamp的最小时间是“1970年1月2日 08:00:00”，也就是说，如果dtime = datetime(1970, 1, 2, 7, 0)时，dtime.timestamp()也会引起OSError错误。
我十分疑惑的地方有三个：
为什么In [4]: dt.timestamp()会出现错误？
为什么能够输出timestamp的最小时间是datetime(1970, 1, 2, 8, 0)？
为什么In [7]: dtime.timestamp()的输出是24小时，而不是24+8小时？
显式加入时区看一看
从In [3]: print(dt)的输出来看，我们发现，用类似于datetime(1970, 1, 1, 0, 0)这样的语句，是隐式采用系统所在时区的。现在，我们来显式指定时区：
这里，需要说一下背景知识：
以伦敦格林尼治天文台所在为本初子午线，定为零时区（中时区）。向东为+时区，向西为-时区。
replace函数显式地强制地将时区转换为tzinfo参数所指定地时区。此时，你应该注意In [12]: print(dt8)的输出，dt8是从dt转换过来地，dt是1970-01-01 00:00:00，dt8也是这个时间，但后面多了一点东西：+08:00
我用dt8表示东八区，即北京所在时区，用dt0表示中时区，即伦敦所在时区，用dt_8表示西八区。
好了，来解释代码：
我们从In [9]: print(dt0)的输出中看到+00:00，这代表dt0的意思是中时区的1970-01-01 00：00：00，我们都知道，timestamp是相对于epoch time的秒数，Out[10]: 0.0证明了这一点。
从In [12]: print(dt8)的输出中看到+08:00,这代表dt8的意思是东八区的1970-01-01 00：00：00。东八区比中时区早8个小时，所以，由于timestamp是相对于epoch time的秒数，所以dt8.timestamp()应该是-8小时，Out[13]: -28800.0验证了这一点。
接下来的dt_8就很容易理解了，和dt8是一样道理。dt_8是西八区，比中时区少8小时，所以要加8小时才能“到达”中时区。Out[16]: 28800.0验证了这一点。
其实，到了这里，我们已经可以解答上面提出的第三个疑惑了：为什么In [7]: dtime.timestamp()的输出是24小时，而不是24+8小时？
我们定义的时间是01-02 08:00,按照惯性思维01-02 08:00-01-01 00：00等于24+8小时，没毛病呀？为什么结果不是这样呢？
真正的原因是：
dtime是东八区的时间，换算为中时区的时间应该是1970-01-02 00:00。所以，1970-01-02 00:00-1970-01-01 00：00等于24小时。总之，你要时刻记住：timestamp是相对于epoch time的秒数。
解决最后的问题
其实，要回答最后的问题，只需要知道一点点东西就够了，那便是显式指定时区和隐式采用系统时区的区别。
我们从回答问题开始：为什么能够输出timestamp的最小时间是datetime(1970, 1, 2, 8, 0)？
隐式采用系统所在时区时，类似于dtime.timestamp()这样的输出不可以有负数。这是为了应对在实际应用中世界各地的时间能够统一。那么，怎么能让timestamp不为负数呢？就是相对于中时区，从1970-01-02 00：00开始算起，这是中时区的最小时间。这样的话，我无论向东还是向西都不会出现负数。由于，我们用的时北京时间，即东八区，所以，最小时间是1970-01-02 08：00
同样道理，如果我们在东一区，那么我们的最小时间是1970-01-02 01：00，为了验证，我开了虚拟机，并且把时区调到东一区，下面是输出：
现在只剩下最后的问题了：
为什么In [4]: dt.timestamp()会出现错误？
到了这里，我们可以看官方文档的东西了。我截取官方的一段话：
There is no method to obtain the POSIX timestamp directly from a naive datetime instance representing UTC time. If your application uses this convention and your system timezone is not set to UTC, you can obtain the POSIX timestamp by supplying tzinfo=timezone.utc
大意是我们无法直接从原生的datetime实例中直接获取代表utc时间的timestamp,你可以通过应用tzinfo=timezone.utc来获取timestamp。
注意：还记得我们前面说过的这句话吗：
replace函数"显式地"强制地将时区转换为tzinfo参数所指定地时区。
这里的原生的datetime实例其实已经隐式地采用了你系统所在时区了。看代码：
dtest和dtest1的输出是一样的，这里说明了如果不显式指定系统时区，就隐式采用系统所在时区。这里，建议你往上拉一下，再看一看显式指定和隐式采用系统所在时区的区别。隐式时要从1970-01-02 +时区算起，即不能出现负数。
现在，我们指定tzinfo的参数，发现dt能输出了。
结尾
文章有点啰嗦。要说明的一点是：所谓的显式和隐式是为了帮助我理解概念我自己写的。其实如果你是位很聪明且基础好的人，看到下面这段话就已经全明白了：
Changed in version 3.6: The timestamp() method uses the fold attribute to disambiguate the times during a repeated interval.There is no method to obtain the POSIX timestamp directly from a naive datetime instance representing UTC time. If your application uses this convention and your system timezone is not set to UTC, you can obtain the POSIX timestamp by supplying tzinfo=timezone.utc
网友评论