pd.to_datetime()默认返回无时区的naive datetime，即使字符串含+08:00或z；需显式使用utc=true、infer_timezone=true或配合tz_localize()/tz_convert()处理时区。
为什么 pd.to_datetime() 解析后没有时区信息？
默认情况下，pd.to_datetime() 返回的是 naive datetime（无时区），即使原始字符串含 +08:00 或 Z。这不是 bug，而是 Pandas 的设计选择：它把时区解析当作可选步骤，需显式触发。
常见错误现象：pd.to_datetime("2023-01-01T12:00:00+08:00") 返回 2023-01-01 12:00:00，但 .dt.tz 是 None。
- 必须加参数
utc=True或infer_timezone=True（后者不推荐，不可靠） - 更稳妥的做法是先转为 naive，再用
.dt.tz_localize()显式赋时区 - 若字符串含 UTC 偏移（如
+08:00），优先用utc=True→ 自动转为 UTC-aware，再用.dt.tz_convert()
如何安全地把本地时间字符串转成目标时区的 timestamp？
典型场景：日志里记录的是「北京时间字符串」"2024-05-20 09:30:00"，你想转成 America/New_York 对应的时刻（即同一物理时刻，在纽约显示为几点）。
关键在于两步不能颠倒：先 localize（声明“这是东八区的时间”），再 convert（换算成其他时区）。反着来会出错。
-
df["ts"] = pd.to_datetime(df["ts_str"])→ 得到 naive datetime -
df["ts"] = df["ts"].dt.tz_localize("Asia/Shanghai")→ 声明来源时区（注意不是+08:00，要用 IANA 名） -
df["ts_ny"] = df["ts"].dt.tz_convert("America/New_York")→ 换算目标时区 - 如果源字符串已带偏移（如
"2024-05-20 09:30:00+08:00"），直接pd.to_datetime(..., utc=True)更省事
tz_localize() 报错 Cannot localize tz-aware datetime 怎么办？
这是最常踩的坑：对已经带时区的 Series 再调用 .dt.tz_localize()，Pandas 会拒绝执行并抛出该错误。
根本原因是混淆了「给 naive 时间打上时区标签」和「把已有时区的时间换算成另一个时区」——前者用 tz_localize，后者用 tz_convert。
- 检查是否重复调用：
df["ts"].dt.tz若不为None，就别再tz_localize - 不要写
df["ts"].dt.tz_localize("UTC").dt.tz_localize("Asia/Shanghai")—— 第二步必然失败 - 不确定是否有时区？先用
df["ts"].dt.tz is None判断，再分支处理 - 批量清洗时，建议统一走「先转 naive → 再 localize → 再 convert」流程，避免状态混乱
用 pytz 还是 zoneinfo？Pandas 1.4+ 用户注意兼容性
Pandas ≥ 1.4 默认使用 zoneinfo（Python 3.9+ 标准库），但很多旧代码仍用 pytz。混用会导致 TypeError: Cannot compare tz-naive and tz-aware dtypes 类错误。
根本影响是时区对象不互通：pytz.timezone("Asia/Shanghai") 和 ZoneInfo("Asia/Shanghai") 虽然语义相同，但在 Pandas 内部视为不同类型。
- 新项目一律用
ZoneInfo（from zoneinfo import ZoneInfo），传给tz_localize()或tz_convert() - 若必须兼容老环境（Python pytz，但注意
pytz的localize()方法不能直接传给 Pandas，得用字符串名（如"Asia/Shanghai"） - 避免手动构造
pytz对象再塞进 Pandas；Pandas 内部会自动转换字符串名为对应时区实例
.dt.tz 状态，并严格按「先声明、再换算」顺序走，就能避开绝大多数问题。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
