我正在编写一个程序，它处理很多时区并跨越它们。我处理最多的两件事是从“现在”创建一个日期时间对象，然后本地化一个简单的日期时间对象。
要从现在开始在太平洋时区创建一个日期时间对象，我目前正在这样做（python 2.7.2+）
from datetime import datetime
import pytz
la = pytz.timezone("America/Los_Angeles")
now = datetime.now(la)
这对于 DST 是否正确？如果没有，我想我应该这样做：
now2 = la.localize(datetime.now())
我的问题是为什么？谁能告诉我第一个错误而第二个正确的案例？
至于我的秒数问题，假设我在 2012 年 9 月 1 日上午 8:00 在加利福尼亚州洛杉矶的一些用户输入中有一个天真的日期和时间。是这样制作日期时间的正确方法：
la.localize(datetime(2012, 9, 1, 8, 0))
如果没有，我应该如何构建这些日期时间？
从pytz 文档：
处理时间的首选方式是始终以 UTC 工作，仅在生成供人类阅读的输出时转换为本地时间。
所以理想情况下你应该使用utcnow而不是now.
假设由于某种原因您的双手被束缚并且您需要使用当地时间，如果您在夏令时转换窗口期间尝试本地化当前时间，您仍然会遇到问题。同样的datetime情况可能会发生两次，一次是在白天，一次是在标准时间，并且该localize方法不知道如何解决冲突，除非您使用is_dst参数明确告诉它。
因此要获取当前的 UTC 时间：
utc = pytz.timezone('UTC')
now = utc.localize(datetime.datetime.utcnow())
并将其转换为您的当地时间（但仅在您必须时）：
la = pytz.timezone('America/Los_Angeles')
local_time = now.astimezone(la)
编辑：正如@JF Sebastian在评论中指出的那样，您使用的第一个示例datetime.now(tz)将适用于所有情况。如上所述，您的第二个示例在秋季过渡期间失败。我仍然主张使用 UTC 而不是本地时间来显示除显示之外的所有内容。
对于 DST，第一个解决方案是正确的，而第二个解决方案是不好的。
我举个例子。在欧洲，运行此代码时：
from datetime import datetime
import pytz # $ pip install pytz
la = pytz.timezone("America/Los_Angeles")
fmt = '%Y-%m-%d %H:%M:%S %Z%z'
now = datetime.now(la)
now2 = la.localize(datetime.now())
now3 = datetime.now()
print(now.strftime(fmt))
print(now2.strftime(fmt))
print(now3.strftime(fmt))
我得到以下信息：
2012-08-30 12:34:06 PDT-0700
2012-08-30 21:34:06 PDT-0700
2012-08-30 21:34:06
datetime.now(la)使用 LA 的当前时间以及 LA 的时区信息创建日期时间。
la.localize(datetime.now())将时区信息添加到天真的日期时间，但不进行时区转换；它只是假设时间已经在这个时区。
datetime.now()使用本地时间创建一个简单的日期时间（没有时区信息）。
只要您在洛杉矶，您就不会看到差异，但是如果您的代码曾经在其他地方运行，它可能不会按照您的意愿行事。
除此之外，如果您需要认真处理时区，最好将所有时间都放在 UTC 中，这样可以省去很多 DST 的麻烦。
这有效：
# naive datetime
d = datetime.datetime(2016, 11, 5, 16, 43, 45)
utc = pytz.UTC # UTC timezone
pst = pytz.timezone('America/Los_Angeles') # LA timezone
# Convert to UTC timezone aware datetime
d = utc.localize(d)
>>> datetime.datetime(2016, 11, 5, 16, 43, 45, tzinfo=<UTC>)
# show as in LA time zone (not converting here)
d.astimezone(pst)
>>> datetime.datetime(2016, 11, 5, 9, 43, 45,
tzinfo=<DstTzInfo 'America/Los_Angeles' PDT-1 day, 17:00:00 DST>)
# we get Pacific Daylight Time: PDT
# add 1 day to UTC date
d = d + datetime.timedelta(days=1)
>>> datetime.datetime(2016, 11, 6, 16, 43, 45, tzinfo=<UTC>)
d.astimezone(pst) # now cast to LA time zone
>>> datetime.datetime(2016, 11, 6, 8, 43, 45,
tzinfo=<DstTzInfo 'America/Los_Angeles' PST-1 day, 16:00:00 STD>)
# Daylight saving is applied -> we get Pacific Standard Time PST
这不起作用：
# naive datetime
d = datetime.datetime(2016, 11, 5, 16, 43, 45)
utc = pytz.UTC # UTC timezone
pst = pytz.timezone('America/Los_Angeles') # LA timezone
# convert to UTC timezone aware datetime
d = utc.localize(d)
>>> datetime.datetime(2016, 11, 5, 16, 43, 45, tzinfo=<UTC>)
# convert to 'America/Los_Angeles' timezone: DON'T DO THIS
d = d.astimezone(pst)
>>> datetime.datetime(2016, 11, 5, 9, 43, 45,
tzinfo=<DstTzInfo 'America/Los_Angeles' PDT-1 day, 17:00:00 DST>)
# we are in Pacific Daylight Time PDT
# add 1 day to LA local date: DON'T DO THAT
d = d + datetime.timedelta(days=1)
>>> datetime.datetime(2016, 11, 6, 9, 43, 45,
tzinfo=<DstTzInfo 'America/Los_Angeles' PDT-1 day, 17:00:00 DST>)
# Daylight Saving is NOT respected, we are still in PDT time, not PST
结论：
datetime.timedelta() 不考虑夏令时。
总是在 UTC 时区加/减你的时间。转换为本地时间仅用于输出/显示。
pytz网站说：
不幸的是，对于许多时区，使用标准日期时间构造函数的 tzinfo 参数对 pytz “不起作用”。
所以你不应该使用datetime.now(la). 我不知道具体情况，但有些时区运行的规则比我们习惯的更奇特，python 的日期时间代码无法处理它们。通过使用 pytz 的代码，应该正确处理它们，因为这是 pytz 的目的。由于夏令时的跳跃时间，它也可能会出现两次出现的问题。
至于第二个问题，这正是文档显示的内容，所以你应该很好。