time.time() 返回utc时间戳，time.mktime() 返回本地时区视角的秒数，二者语义不同；跨时区应优先用datetime+zoneinfo，避免time模块的平台与时区陷阱。
time.time() 和 time.mktime() 返回的不是同一类时间戳
很多人以为 time.time() 和 time.mktime() 都返回“秒级时间戳”，直接混用不会出错——其实它们语义完全不同：time.time() 返回的是 UTC 时间戳（自 1970-01-01 00:00:00 UTC 起的秒数），而 time.mktime() 接收的是本地时区的 struct_time，返回的是**本地时区视角下的秒数**（即等价于本地时间转成 UTC 后再算秒数）。在非 UTC 时区（比如中国是 UTC+8），两者数值差 28800 秒（8 小时）。
常见错误现象：time.mktime(time.strptime("2024-01-01 00:00:00", "%Y-%m-%d %H:%M:%S")) 得到的值比预期早了 8 小时，后续传给 datetime.fromtimestamp() 又自动按本地时区解释，结果变成 2023-12-31 16:00:00，彻底错乱。
- 用
time.mktime()前，务必确认输入的struct_time是按本地时区理解的；否则应改用calendar.timegm()+time.strptime(..., "%Y-%m-%d %H:%M:%S") -
time.time()永远是 UTC 基准，但它的返回值类型是 float，小数部分代表微秒，直接 int() 截断会丢精度 - 跨时区场景下，别依赖
time模块做转换，优先用datetime+zoneinfo（Python 3.9+）或pytz
datetime.fromtimestamp() 默认按系统本地时区解释时间戳
datetime.fromtimestamp() 不是“把时间戳还原成原始时间”，而是“把时间戳当作 UTC 时间，再转换成本地时区显示”。如果你拿到一个明确是 UTC 时间戳（比如 API 返回的 "created_at": 1704067200），却用 datetime.fromtimestamp(1704067200)，在中国就会显示为 2024-01-01 08:00:00——它多加了 8 小时。
正确做法是显式指定时区：
立即学习“Python免费学习笔记（深入）”；
- UTC 时间戳 → UTC 时间对象：
datetime.datetime.fromtimestamp(1704067200, tz=datetime.timezone.utc) - 本地时间戳 → 本地时间对象（不推荐）：
datetime.datetime.fromtimestamp(1704067200)，仅当该时间戳本就是按本地时区生成时才安全 - 如果必须用
time模块，time.gmtime(1704067200)总是返回 UTC 的struct_time，比time.localtime()更可控
strptime 解析字符串时忽略时区字段，除非显式指定
time.strptime("2024-01-01T00:00:00Z", "%Y-%m-%dT%H:%M:%SZ") 看似带 Z，但 strptime 完全不处理时区，返回的 struct_time 仍是 naive 的，没有时区信息。后续传给 time.mktime() 或 time.timegm() 就容易误判。
更糟的是，%z 格式符只能解析 +0800 这类偏移，不能识别 Z 或 UTC 字符串，且 Python 3.6 之前还不支持 %z 解析带冒号的偏移（如 +08:00）。
- 含时区的字符串，优先用
datetime.fromisoformat()（Python 3.7+），它原生支持Z和+08:00 - 必须用
strptime时，先用正则提取时区部分，再手动构造timezone对象拼接 -
datetime.strptime()同样不带时区解析能力，和time.strptime()一样 naive，别被名字误导
Windows 下 time.mktime() 对早于 1970 年的时间处理不可靠
Windows 的 C 运行时对负时间戳（即 1970 年前）支持不一致。time.mktime((1969, 12, 31, 23, 59, 59, 2, 365, 0)) 在某些版本会返回 -1 或抛 ValueError，而 Linux 下通常能正常工作。这不是 Python 的 bug，是底层 libc 行为差异。
这导致跨平台代码在处理历史日期、测试边界 case 时突然失败。
- 避免在 Windows 上用
time.mktime()处理 1970 年前时间，改用datetime计算：先构造datetime(1969, 12, 31, 23, 59, 59)，再调.timestamp()（注意它仍会转成本地时区 timestamp） - 如果需要统一行为，所有时间操作尽量收敛到
datetime+ 显式tzinfo，绕过time模块的平台差异 - CI 测试中若覆盖 Windows，建议加一条 assert 检查
time.mktime()对 (1970,1,1,0,0,0,...) 是否返回 >= 0
真正麻烦的不是语法怎么写，而是每个函数背后藏着的时区假设、平台限制、模块分工模糊——这些边界一旦没对齐，时间就悄悄漂移了。
