pytz：为何在时区转换时需要规范化？

Question

我在看那个不太完整的 pytz 文档，有一部分我搞不懂。

在不同的时区之间转换时，需要特别注意。这也需要使用 normalize 方法，以确保转换是正确的。

>>> utc_dt = utc.localize(datetime.utcfromtimestamp(1143408899))
>>> utc_dt.strftime(fmt)
'2006-03-26 21:34:59 UTC+0000'
>>> au_tz = timezone('Australia/Sydney')
>>> au_dt = au_tz.normalize(utc_dt.astimezone(au_tz))
>>> au_dt.strftime(fmt)
'2006-03-27 08:34:59 EST+1100'
>>> utc_dt2 = utc.normalize(au_dt.astimezone(utc))
>>> utc_dt2.strftime(fmt)
'2006-03-26 21:34:59 UTC+0000'

我试了这个例子，没有使用 normalize，结果还是一样的。在我看来，这个例子并没有真正解释 为什么 在转换不同时区的 datetime 对象时，我们必须使用 normalize。

有没有人能给我一个 例子（像上面那个），说明不使用 normalize 时结果会有什么不同。

谢谢

Answer 1

文档中提到，normalize是用来解决夏令时（DST）问题的一个方法：

另外，如果你在跨越夏令时边界的本地时间上进行日期计算，结果可能会显示在错误的时区（比如，从2002年10月27日1:00 EST减去1分钟，你得到的结果是2002年10月27日0:59 EST，而不是正确的2002年10月27日1:59 EDT）。为了解决这个问题，提供了一个normalize()的方法。

所以，它是用来修正一些涉及夏令时的特殊情况。如果你不使用夏令时的时区（例如UTC），那么就不需要使用normalize。

如果你不使用这个方法，在某些情况下你的时间转换可能会出现一小时的误差。

Answer 2

来自pytz文档的内容：

另外，如果你在跨越夏令时（DST）边界的本地时间上进行日期计算，结果可能会显示在错误的时区里（比如，从2002年10月27日1:00东部标准时间减去1分钟，你得到的结果是2002年10月27日0:59东部标准时间，而不是正确的2002年10月27日1:59东部夏令时间）。为了纠正这个问题，提供了一个normalize()方法。不幸的是，这些问题无法解决，除非修改Python的日期时间实现。