Python计算时间差出现-1day：机器人uptime指令跨午夜异常排查

你遇到的-1 day异常，本质是两个问题叠加导致的，完全不是你定义的时分秒格式出了问题：

• 关键日期信息丢失：落盘文件时只存了时分秒，完全没有记录机器人启动时的具体日期。当Python用strptime解析纯%H:%M:%S格式的字符串时，会自动给这个时间绑定默认的1900-01-01日期。一旦跨午夜，比如启动时间是前一天的23:50:00，当前时间是当天00:10:00，两个被强行绑定在同一日期的时间做减法，结果就是00:10:00 - 23:50:00 = -23小时40分钟。
• timedelta的内置显示逻辑：Python的timedelta对象内部固定用「天、秒、微秒」三个维度存储时间差，只要计算出的差值是负数，就会自动把负的小时数折算成负的天级单位，最终打印出来就是-1 day, 00:20:00的格式——这和你解析时间时的格式定义没有关系，哪怕你输入的只有时分秒，只要差值为负，就一定会触发这种带天的显示。

之前不跨午夜时计算正常，是因为同一天内当前时间一定晚于启动时间，差值为正，自然不会触发折算负天的逻辑。

核心思路 #

不要依赖纯时分秒做差值计算，跨天场景下纯时分秒的信息没有足够的参考价值，必须记录启动的绝对时间点才能准确计算在线时长。最稳定无歧义的方案是落盘保存启动时刻的Unix时间戳（从1970年1月1日到启动时刻的总秒数），完全避免日期回绕的判断误差。

修正后的完整实现 #

from datetime import datetime
import os
import time

folder = r"C:\Users\Ryan Mclaughlin\PycharmProjects\Snappingbot-V2\SnappingbotV2\text files"
filename = "uptime.txt"
fp = os.path.join(folder, filename)

# 机器人启动时：写入绝对时间戳，无任何格式歧义
with open(fp, "w") as f:
    f.write(str(time.time()))

# 读取启动时间戳，全程用上下文管理器释放文件句柄
with open(fp, "r") as f:
    startup_ts = float(f.readline().strip())
startup_time = datetime.fromtimestamp(startup_ts)

# 计算到当前时刻的时间差
time_now = datetime.now()
tdelta = time_now - startup_time

# 把时间差转成预期的可读格式，将天级部分折算为小时
total_seconds = int(tdelta.total_seconds())
hours = total_seconds // 3600
minutes = (total_seconds % 3600) // 60
seconds = total_seconds % 60
print(f"机器人已在线{hours}小时{minutes}分钟{seconds}秒")

方案优势 #

• 时间戳是绝对的时间点，不存在“当前时间是启动当天还是跨了N天”的判断难题，哪怕机器人连续跑100天，计算出的差值也一定是正数，不会出现负的天级单位
• 格式化时主动把总秒数折算成小时维度，不会出现原始timedelta显示“X天Y小时”的情况，完全匹配你预期的输出格式
• 所有文件读写都用上下文管理器，不会出现文件句柄未释放、Windows下文件被占用的问题

注意：如果硬要坚持只存时分秒的方案，最多只能通过「检测到当前时分早于启动时分时，给差值补24小时」的逻辑处理跨1个午夜的场景，一旦机器人跨了两个以上的午夜（比如第一天23点启动，第三天1点查询时长），这种方案依然会计算错误，完全不推荐。

内容的提问来源于stack exchange，提问作者Ryan Mclaughlin