time.time() 返回自 Unix 纪元起的 UTC 秒级时间戳，无时区信息；需显式指定时区转换，避免依赖系统本地时区；字符串转时间戳应优先用 fromisoformat 或 dateutil 解析带时区信息，再统一转 UTC。
time.time() 得到的是什么时间戳？
time.time() 返回的是自 Unix 纪元（1970-01-01 00:00:00 UTC）起的秒数，纯数值，无时区信息。它本质上是 UTC 时间的线性表示，不是“本地时间戳”。
- 如果你在东八区调用
time.time()，返回值和伦敦、纽约同一时刻调用的结果完全一致 - 它不包含
tzinfo，不能直接用datetime.fromtimestamp()反推“原始时区” - 错误认知：以为
time.time()是“本地时间戳”——这会导致后续转换全错
正确做法是：把 time.time() 当作 UTC 基准，显式指定目标时区做转换。
用 datetime.fromtimestamp() 转本地时间，为什么结果常出错？
datetime.fromtimestamp() 默认使用系统本地时区（由 time.tzname 或环境变量决定），但这个行为不可靠：
- 在服务器上可能为 UTC（如 Docker 容器未设
TZ） - 在 macOS 和 Windows 上对夏令时处理逻辑不同
- 传入
tz参数才能可控：datetime.fromtimestamp(ts, tz=ZoneInfo("Asia/Shanghai"))
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
- 开发机显示正确，上线后时间偏 8 小时
- 3 月某天时间突然跳变 1 小时（夏令时切换）
建议统一用 zoneinfo.ZoneInfo（Python 3.9+）或 pytz（旧项目），避免依赖系统时区。
如何安全地把字符串时间（带时区）转成 UTC 时间戳？
关键点：字符串里的时区标识（如 +0800、UTC、CST）必须被明确解析，不能靠 guess。
-
datetime.strptime()不支持时区解析，遇到%z会失败（除非手动补零） - 推荐用
datetime.fromisoformat()（支持2023-05-12T14:30:00+08:00）或dateutil.parser.parse()（更宽松，但需装python-dateutil）
实操建议：
- 优先接收 ISO 8601 格式（含时区），用
.fromisoformat()解析 - 若必须处理
"2023-05-12 14:30:00 CST"这类模糊字符串，用dateutil.parser.parse(s, tzinfos={"CST": ZoneInfo("Asia/Shanghai")}) - 解析后统一转成 UTC：
dt.astimezone(ZoneInfo("UTC"))，再用dt.timestamp()得时间戳
跨时区比较两个时间戳，为什么直接比大小会出问题？
时间戳本身是 UTC 基准，数值比较永远安全。真正危险的是：用带时区的 datetime 对象直接比较，而它们没归一化。
典型陷阱：
dt1 = datetime(2023,1,1,12,0,0, tzinfo=ZoneInfo("Asia/Shanghai"))dt2 = datetime(2023,1,1,12,0,0, tzinfo=ZoneInfo("America/New_York"))-
dt1 == dt2→ False（虽然都写 12:00，但实际相隔 13 小时）
安全做法：
- 所有比较前先归一化：
dt1.astimezone(ZoneInfo("UTC")) == dt2.astimezone(ZoneInfo("UTC")) - 或直接转时间戳：
dt1.timestamp() == dt2.timestamp()
时区转换里最易被忽略的点：字符串解析阶段就丢掉了原始时区上下文，后面怎么转都补不回来。宁可多一步验证，也别信“看起来像北京时间”的字符串。
