树莓派3B上Python脚本中time.clock()时间变量执行时变为负数的问题排查与数据修复咨询

为什么time.clock()会在2147秒左右溢出？ #

你猜的没错，这确实是32位有符号整数溢出导致的问题，具体原因是：
在32位Linux（树莓派3B默认是32位系统）上，Python的time.clock()底层依赖C标准库的clock()函数，它返回的是当前进程累计使用的CPU时间，单位是CLOCKS_PER_SEC（通常为1000000，即微秒）。这个数值用32位有符号整数clock_t存储，最大值是2^31 - 1 = 2147483647（微秒），换算成秒就是2147.483647秒。当进程累计CPU时间超过这个值时，有符号整数会溢出，数值直接绕回成负数（比如2147483648微秒会变成-2147483648微秒），除以1e6转成秒后就出现了你看到的负数时间戳。

如何修复已采集的溢出时间数据？ #

因为溢出是32位有符号整数的循环绕回，我们可以通过加上固定偏移量来还原正确的时间值：

1. 溢出后的负数时间，和正确的累计CPU时间的差值刚好是2^32微秒（也就是4294.967296秒）——这是32位无符号整数的整个取值范围。
2. 针对每条负数时间戳，直接加上这个偏移量就能得到正确的数值。

可以用这段Python代码批量处理你的CSV数据：

import csv

def fix_overflowed_time(timestamp):
    # 32位有符号clock_t对应的最大正数秒数
    max_valid_sec = (2**31 - 1) / 1000000  # 2147.483647
    # 溢出修复的偏移量（2^32微秒 = 4294.967296秒）
    overflow_offset = (2**32) / 1000000
    
    if timestamp < 0:
        return timestamp + overflow_offset
    # 额外处理可能的二次溢出（如果程序运行超8589秒的话）
    elif timestamp > max_valid_sec:
        return timestamp - overflow_offset
    else:
        return timestamp

# 示例：读取旧CSV并生成修复后的新CSV
with open("old_data.csv", "r") as infile, open("fixed_data.csv", "w", newline="") as outfile:
    reader = csv.DictReader(infile)
    writer = csv.DictWriter(outfile, fieldnames=reader.fieldnames)
    writer.writeheader()
    
    for row in reader:
        # 把字符串转成浮点数后修复
        fixed_time = fix_overflowed_time(float(row["Time (s)"]))
        row["Time (s)"] = f"{fixed_time:.6f}"  # 保留6位小数和原格式一致
        writer.writerow(row)

运行这段代码后，你的负数时间会被修正为正确的累计CPU时间：

• -2147.336675 → -2147.336675 + 4294.967296 = 2147.630621
• -2147.000555 → -2147.000555 + 4294.967296 = 2147.966741

后续建议：改用time.time() #

你提到的time.time()确实更适合这个场景：

• 它返回的是从1970年1月1日开始的实时时间戳（秒），底层用64位整数存储（即使32位Linux系统也会兼容64位时间），几乎不会出现溢出问题（要到2038年才会碰到32位时间的极限，现在主流系统都已经规避了这个问题）。
• 它记录的是真实的 wall-clock time，对于数据采集的时间戳来说，比CPU时间更有参考价值（CPU时间只记录进程运行的时间，会受到系统负载影响）。

内容的提问来源于stack exchange，提问作者Franz Carl Puchert