Question

我目前正在重写一些旧代码并遇到了这个问题：

gettimeofday(&tv, NULL);
unsigned int t = tv.tv_sec * 1000 + tv.tv_usec / 1000;

这真的看起来他们试图将自Epoch以来的毫秒存储在uint32中。而且我肯定认为这不合适所以我做了一些测试。

#include <sys/time.h>
#include <stdint.h>

int main() {
    struct timeval tv;
    gettimeofday(&tv, nullptr);
    uint32_t t32 = tv.tv_sec * 1000 + tv.tv_usec / 1000;
    int64_t t64 = tv.tv_sec * 1000 + tv.tv_usec / 1000;
    return 0;
}

我说得对：

(gdb) print t32
$1 = 1730323142
(gdb) print t64
$2 = 1423364498118

所以我猜他们正在做的事情并不安全。但他们在做什么，为什么他们这样做，实际发生了什么？ （在这个例子中，左边的10位将丢失，它们只关心差异）它们是否仍然保持毫秒精度？ （是）请注意他们发送此＆＃34;时间戳＆＃34;通过网络，仍然用它来计算。

Answer 1

不，它不安全＆＃34;它牺牲了便携性，准确性或两者兼而有之。

如果你只关心低位，那就是便携式，例如如果您在网络上发送这些时间，然后在另一侧进行差异，最大差异大约为四百万秒（46天）。

如果您只在int为64位的系统上运行此代码，则这是准确的。有一些类似的机器，但并不多。

Answer 2

更安全吗？我可以回答不，是的。我之所以说不，因为在这一天，我们几乎所有位（从一个32位数字）都用来计算自1970年1月以来的纪元。当你乘以1000（十进制）时，你几乎将所有位旋转到左边更接近10位的东西，这意味着失去精度。

我也可以对你的回答说“是”。在您的问题的最后，您说这个数字用于考虑网络中数据包的时间戳。问题是：生活时间有多长？ 10年？ 10天10秒？以毫秒为单位丢失10位将使您有足够的时间在两个精度为毫秒的数据包之间进行计算，我想这就是您想要的

自uint32中的Epoch以来存储毫秒是安全的

2 个答案: