datetime转timestamp前必须处理时区，否则naive时间按本地时区解释会导致跨时区偏差；timestamp转datetime需区分fromtimestamp（本地时区）与utcfromtimestamp（utc），推荐python 3.9+用fromtimestamp(ts, tz=timezone.utc)。
datetime 转 timestamp 用 timestamp() 前必须处理时区
Python 3.6+ 的 datetime.timestamp() 方法看似简单，但对无时区信息的 datetime 对象（即 naive datetime）会默认按本地时区解释——这在服务器部署、跨时区协作或定时任务中极易导致时间偏移。
常见错误现象：datetime(2023, 1, 1, 0, 0) 在上海服务器转出的 timestamp 对应北京时间 0 点，在纽约服务器却变成 EST 0 点（实际是 UTC+5），结果相差 13 小时。
- 安全做法：始终用带时区的
datetime，例如datetime.now(timezone.utc)或dt.replace(tzinfo=timezone.utc) - 若必须处理
naive时间，显式声明其所属时区再转换：dt.replace(tzinfo=timezone(timedelta(hours=8))).timestamp() - 避免依赖
time.time()或系统localtime()做中间桥接，容易引入隐式时区假设
timestamp 转 datetime 时 fromtimestamp() 和 utcfromtimestamp() 语义完全不同
fromtimestamp() 把 timestamp 解释为「本地时区的时刻」，utcfromtimestamp() 则固定按 UTC 解释。两者返回的 datetime 对象在相同 timestamp 下可能差出数小时，且前者返回 naive 对象，后者返回 naive（Python 3.6+）或带 tzinfo=None —— 容易误以为是 UTC。
使用场景：读取日志里记录的 Unix 时间戳（通常为 UTC），却用 fromtimestamp() 直接转，结果在不同时区机器上显示不同时间。
立即学习“Python免费学习笔记（深入）”；
- 明确来源是 UTC？一律用
datetime.utcfromtimestamp(ts)+ 手动补时区：datetime.utcfromtimestamp(ts).replace(tzinfo=timezone.utc) - 需要本地时区显示？用
datetime.fromtimestamp(ts)，但记得它返回的是naive，后续做计算前得先 localize（如用zoneinfo.ZoneInfo） - Python 3.9+ 推荐统一走
datetime.fromtimestamp(ts, tz=timezone.utc)，第三个参数可指定任意时区，语义清晰
跨平台下 timestamp() 对负值时间（1970 年前）行为不一致
Windows 的 timestamp() 在传入早于 1970-01-01 的 datetime 时会直接抛 OSError: [Errno 22] Invalid argument；Linux/macOS 虽支持，但部分 C 库实现对远古时间精度丢失严重（秒级误差可达数分钟）。
参数差异：不是所有 datetime 都能无损 round-trip 成 timestamp，尤其涉及 BC 年份或毫秒级精度时。
- 若业务需处理历史时间，避开
timestamp()，改用datetime.isoformat()或自定义整数编码（如 `(year, month, day)` 元组） - 必须用数值型时间戳？用
calendar.timegm(dt.timetuple())处理 UTC 时间，它不调用系统 C 函数，兼容性更好 - 测试时务必在目标部署环境（尤其是 Windows Server）验证负时间戳路径
用 zoneinfo 替代 pytz 时，astimezone() 不再静默修正夏令时
pytz 的 astimezone() 会对模糊时间（如夏令时切换时刻）自动选择较早/较晚的合法时间；而标准库 zoneinfo（Python 3.9+）默认抛 AmbiguousTimeError 或 NonExistentTimeError，行为更严格但也更易崩。
性能影响：错误未捕获会导致整个请求失败，而非静默偏差；兼容性上，zoneinfo 不支持 Python
- 遇到
AmbiguousTimeError？显式指定fold=0或fold=1来选 DST 前后版本 - 别依赖
astimezone()自动 fallback，提前用tzfile查该时区当年 DST 规则 - 如果仍用
pytz，注意其localize()和astimezone()不能混用同一对象，否则时区信息可能丢失
真正麻烦的从来不是转换本身，而是那些没报错却悄悄偏了两小时的时间——尤其当它们藏在日志聚合、缓存过期、数据库分区键里时。
