datetime默认不带时区是因为设计上优先考虑简单场景，避免强制引入时区概念；naive时间在跨时区、数据库存储、HTTP解析等场景易出错，需用zoneinfo构造aware对象并明确时区语义。
为什么 datetime 默认不带时区？
Python 的 datetime 对象分两类：naive（无时区）和 aware（有时区）。默认构造的 datetime 全是 naive，比如 datetime.now() 或 datetime(2024, 1, 1) —— 它们不记录所在时区，也不说明是本地时间还是 UTC。这本身不是 bug，而是设计取舍：简单场景下避免强制引入时区概念。但一旦涉及跨时区计算、存数据库、解析 HTTP 头里的 Date 字段，naive 时间就立刻失效。
- 如果你用
datetime.now()记录日志，又在另一台机器上用不同系统时区读取，时间可能错 8 小时 -
astimezone()对 naive 对象直接报ValueError: astimezone() cannot be applied to a naive datetime - 数据库如 PostgreSQL 的
TIMESTAMP WITHOUT TIME ZONE列会静默丢弃时区信息，导致后续转换出错
pytz 为何被弃用，zoneinfo 怎么用？
pytz 曾是事实标准，但它内部用“先 localize 再转换”的两步模型，容易写出 dt.replace(tzinfo=pytz.timezone('Asia/Shanghai')) 这类错误代码——这不会做时区转换，只是硬塞一个错误的 tzinfo。Python 3.9+ 推荐用标准库 zoneinfo，它基于 IANA 时区数据库，API 更直觉：
- 用
ZoneInfo('Asia/Shanghai')直接构造时区对象，支持所有标准时区名 -
datetime.now(ZoneInfo('UTC'))返回带 UTC 时区的 aware 对象 - 转换时直接调
dt.astimezone(ZoneInfo('America/New_York'))，无需 localize 步骤 - 注意：Windows 上需额外安装
tzdata包（pip install tzdata），否则ZoneInfo初始化失败
夏令时（DST）切换时的典型陷阱
夏令时不是简单加一小时，而是一段“模糊时间”或“跳跃时间”。例如美国东部时间 2024 年 3 月 10 日 2:00 AM 会跳到 3:00 AM；11 月 3 日 2:00 AM 会重复一次。这时：
-
datetime(2024, 3, 10, 2, 30, tzinfo=ZoneInfo('America/New_York'))会抛AmbiguousTimeError或NonExistentTimeError（取决于具体值） - 不要用字符串拼接构造带时区的时间，比如
'2024-03-10 02:30:00 EST'—— EST 在 DST 期间其实不生效，应统一用America/New_York - 解析用户输入的时间字符串时，务必明确指定目标时区，而不是依赖系统本地时区（
time.tzname不可靠）
与常见外部系统交互时的时区约定
时区混乱往往发生在边界上：
立即学习“Python免费学习笔记（深入）”；
- HTTP
Date响应头、RFC 3339 时间戳（如2024-01-01T12:00:00Z）默认是 UTC，解析后应设为ZoneInfo('UTC')，而非系统本地时区 - Pandas 的
pd.Timestamp和pd.to_datetime()默认返回 naive，加参数utc=True或tz='UTC'才生成 aware 时间 - Django 的
USE_TZ = True会让datetime.now()返回 UTC 时间，但模板中显示仍需显式调|timezone:"Asia/Shanghai"，否则按服务器本地时区渲染
时区真正的复杂点不在 API，而在“同一时间在不同上下文里有不同含义”——数据库存的是什么、前端传的是什么、日志打的是什么、用户心里想的是什么，四者未必一致。处理时别假设“本地即合理”，先确认每个环节的时区语义。
