如何用double可靠传递微秒级时间？打包顺序为何影响精度？

现象原因解释 #

你遇到的偏差问题核心在于IEEE-754 double类型的有效精度限制：

• double是64位浮点数，其中52位是尾数（加上隐含的1位，总共53位有效二进制精度），这意味着只有≤2^53的整数能被double精确表示，超出范围的整数，低位二进制位会被舍入。
• 当你把秒（32位，当前UTC秒约为1.7e9，二进制占31位）放在高位、微秒（32位）放在低位时，整个64位整数的大小为 秒 * 2^32 + 微秒，其二进制位数约为31+32=63位，远超double的53位精度。此时低10位（63-53）会被舍入，而这部分正好属于微秒的二进制位，因此解析后微秒会出现±1~500us的偏差。
• 而你最初的正序打包（微秒高位、秒低位）时，整个整数是 微秒 * 2^32 + 秒，微秒最大为999999（二进制仅20位），总二进制位数为20+32=52位，刚好在double的53位精度范围内，因此转存后能完全精确恢复。

可靠实现建议 #

方案1：保留正序打包（推荐） #

继续使用你最初的正序打包方式，它能保证完全精确无损失，只需和接收端约定好打包顺序即可：

timeval tv;
gettimeofday(&tv, nullptr);

// 正序打包：微秒(32位) <<32 | 秒(32位)
uint64_t ts = (static_cast<uint64_t>(tv.tv_usec) << 32) | static_cast<uint32_t>(tv.tv_sec);
double dts = static_cast<double>(ts);

// 解析还原
uint64_t restored_ts = static_cast<uint64_t>(dts);
unsigned int restored_usec = static_cast<unsigned int>(restored_ts >> 32);
unsigned int restored_sec = static_cast<unsigned int>(restored_ts & 0xFFFFFFFF);

方案2：整数+小数拆分打包（若接收端要求秒为整数部分） #

如果接收端必须要求秒作为double的整数部分，微秒作为小数部分，可以采用以下方式：

timeval tv;
gettimeofday(&tv, nullptr);

// 打包：秒 + 微秒/1e6
double dts = static_cast<double>(tv.tv_sec) + static_cast<double>(tv.tv_usec) / 1000000.0;

// 解析还原
time_t restored_sec = static_cast<time_t>(floor(dts));
unsigned int restored_usec = static_cast<unsigned int>(round((dts - restored_sec) * 1000000.0));

注：使用round而非直接取整，是为了抵消double对小数部分的微小舍入误差，确保微秒值的准确性。测试表明，这种方式对0~999999的微秒值均能精确还原。

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