我偶然发现了
>>> a = datetime.datetime(2017, 12, 24)
>>> b = datetime.datetime(2017, 12, 24, tzinfo=datetime.timezone.utc)
>>> a - b
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: can't subtract offset-naive and offset-aware datetimes
现在我想知道：为什么没有所有日期时间对象成为时区？时区是否超过UTC的偏移量（+相关名称）？
答案 0 :(得分：2)
因为时区不重要而且不仅仅是简单的偏移，并非所有用例都需要考虑时区。
时区通常不仅仅是UTC的偏移量。例如，时区也可能决定夏令时（当夏季和冬季之间的时区切换时）。
并非所有用例都需要处理DST，有时您的日期时间值的字符串表示仅包含与UTC的偏移量。但这并不意味着您可以假设 general 中的时区处理只需要处理偏移量。
时区也随着时间的推移改变;什么物理位置使用什么确切的时区可以改变，以及时区的规则。因为地球是一个大的地方，这种情况比你想象的更频繁。不仅DST规则或地理范围可以改变，但时区偏移也是如此。有关历史时区更改的示例，请参阅Jon Skeet's highest voted answer，其中数据库条目也已随时间更正。
这些更改肯定比Python版本更频繁地发生。因此，Python无法为标准库提供全面的时区数据库，并希望它能够保持最新状态直到下一个版本。相反，Python维护者依靠第三方库来生成这样的数据库;这样的库可以遵循更积极的发布周期。
但是，许多涉及日期时间计算的用例不需要包含时区;他们可以而且应该是时区不可知论者。迫使所有这些用例无论如何都要使用时区会给开发人员带来不必要的负担，然后必须了解如何使用包含时区信息的其他日期时间值来处理计算。
因此，datetime库区分了简单的＆＃39;没有时区的日期时间值，以及带有时区的日期时间值。在Python 3.2之前，该库甚至没有包含timezone对象;留给第三方图书馆。当前datetime.timezone() support是支持简单偏移时区而没有历史记录或DST支持;那些至少不需要不断维护和更新的人。
时区的规范Python实现是pytz package，它打包Olson database（由类似UNIX的操作系统（包括Mac OS X）使用）。每当更新Olson数据库时，都会创建一个新版本;我期待2018-01发布的最新版本能够打包最近的2018c版本。
请注意datetime图书馆设计没有预料到必须处理pytz包含时区的历史时区变化;请按照pytz文档操作，并使用timezone.localize(naive_datetime)为日期应用正确的偏移量。见How to make an unaware datetime timezone aware in python
python-dateutil package还包含时区支持。