Python处理时区应区分naive与aware时间，优先用zoneinfo（Python 3.9+）创建感知时间，跨时区转换必用astimezone()，运算需统一时区类型，存储和传递推荐标准化为UTC。
处理带时区的日期时间是Python开发中常见但容易出错的一环。关键在于区分“天真时间（naive）”和“感知时间（aware）”，并始终用datetime.timezone或zoneinfo（Python 3.9+）来明确时区，避免依赖系统本地时区或pytz的过时模式。
用 zoneinfo 正确创建带时区的时间
Python 3.9起标准库提供zoneinfo模块，替代已弃用的pytz推荐做法。
- 从IANA时区数据库加载时区：
from zoneinfo import ZoneInfo； - 创建感知时间：用
datetime(..., tzinfo=ZoneInfo("Asia/Shanghai"))，不能对天真时间直接赋值tzinfo； - 获取当前时间要带时区：
datetime.now(ZoneInfo("Europe/Berlin"))，而非datetime.now().replace(tzinfo=...)（会出错）。
安全地进行跨时区转换
时区转换不是简单加减小时数，必须通过astimezone()方法完成，它自动处理夏令时与历史偏移变更。
- 确保原始时间是aware：只有感知时间才能调用
astimezone()； - 转换目标时区也用
ZoneInfo实例，如.astimezone(ZoneInfo("America/New_York"))； - 不要用
strftime后手动拼接时区名——显示格式应与逻辑分离，时区信息由tzname()或%Z自动给出。
日期运算：避开 naive 时间陷阱
对带时区的时间做加减运算（如+ timedelta(days=1)）是安全的，结果仍保持时区信息；但混合naive与aware时间会报错。
立即学习“Python免费学习笔记（深入）”；
- 所有参与运算的时间对象必须同为aware，或全部naive；
- 若需从字符串解析带时区时间，优先用
datetime.fromisoformat()（支持"2024-05-20T14:30:00+08:00"）； - 解析非ISO格式（如
"2024/05/20 14:30 CST"）时，先用strptime得naive时间，再用.replace(tzinfo=...)——仅当确认该缩写对应唯一时区且无歧义时才这么做。
实用技巧：UTC作为中转基准
在系统间传递时间、存储到数据库或做跨时区比较时，统一转为UTC最可靠。
- 入库前：用
.astimezone(ZoneInfo("UTC"))标准化； - 展示前：再转回用户本地时区；
- 计算间隔（如“距离截止时间还有多久”）：两个aware时间相减，返回的
timedelta不含时区，可直接使用。
不复杂但容易忽略：只要坚持“创建即aware、转换用astimezone、存储用UTC”，就能避开绝大多数时区坑。
