You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

为何Python的datetime.timestamp结果与1970年以来总秒数不一致

问题核心原因:无时区信息的datetime对象的处理逻辑差异
  • 你代码中创建的datetime.datetime(2020, 1 , 1, 0, 0, 0)和datetime.datetime(1970,1,1,0,0,0)都属于naive datetime对象,没有绑定任何时区信息,两种计算方式对这类对象的处理规则不同。
  • datetime.datetime.timestamp()方法处理naive对象时,会默认将其识别为你当前操作系统的本地时区时间,先转换为UTC时间,再计算和1970年1月1日0点(UTC基准)的秒数差,符合Unix时间戳的标准定义。
  • 手动做时间差计算时,只是直接计算两个时间的字面差值,不会做任何时区转换,相当于默认将两个时间视为相同时区下的时间做差,和Unix时间戳的UTC基准规则不符。

你输出的两个结果差值为25200秒,正好是7小时,说明你当前设备的时区为UTC+7,timestamp()方法把你输入的2020年1月1日0点识别为UTC+7时区的时间,转换为UTC时间后是2019年12月31日17点,对应的时间戳正好是1577862000,和手动计算的字面差值1577836800的差异完全匹配时区差。

修复方案

明确给datetime对象绑定UTC时区,两种方式的计算结果就会完全一致:

import datetime
from datetime import timezone

# 明确指定时间为UTC时区的2020-01-01 0点
date = datetime.datetime(2020, 1 , 1, 0, 0, 0, tzinfo=timezone.utc)
# 用UTC时区的Unix纪元时间计算差值
time2 = (date - datetime.datetime(1970,1,1,0,0,0, tzinfo=timezone.utc)).total_seconds()
time1 = date.timestamp()

print(time1 == time2) # 输出结果为 True

内容的提问来源于stack exchange,提问作者trazz

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.10.04 00:39:04