2038 年嵌入式 Linux（32 位）解决方案？ [复制]

Question

在 32 位嵌入式 Linux (ARMLinux) 的 C 代码中处理时间的正确方法是什么，以确保代码在 2038 年 1 月 19 日 UTC 03:14:07 之后继续正常工作（当签名的 32 位time_t 溢出）？鉴于 time_t 在我必须使用的系统上是 32 位签名的，有哪些替代方案？

大量的谷歌搜索没有发现任何实际用途。似乎每个人都认为到那时我们都将使用 64 位操作系统，但这显然不适用于嵌入式系统。

在我需要使用的系统上，__kernel_time_t 被定义为long。这大概意味着 64 位时间没有内核设施。 uClibc的版本是0.9.29。

我不敢相信我是唯一一个遇到这个问题的人，而且我不想重新发明轮子。

Answer 1

没有灵丹妙药、技巧或聪明的解决方案。要么使用具有 64 位 time_t 的操作系统，要么不使用 time_t 和任何依赖于它的操作系统设施（包括文件系统、计时器、半网络等），或者计划在下一个更新软件20 年。

在 32 位机器上至少有两个具有 64 位 time_t 的类 unix 系统：OpenBSD 和 NetBSD。 OpenBSD 进行了几次会谈，解释了其背后的原因：http://www.openbsd.org/papers/eurobsdcon_2013_time_t/index.html

Answer 2

如果时间戳低于某个值，时间转换例程将“简单地”使用 2038-01-19:03:14:07Z 作为 Unix 纪元时间的基础。

即如果您的系统在 2010 年 1 月 1 日开始生产，您可以假设没有未溢出的时间戳低于 1262300400（这是该日期的 unix 纪元时间）。

如果遇到较低的时间戳，则认为它已溢出并使用 2038-01-19:03:14:07Z 作为基准时间。比较也必须考虑在内。

不是一个干净的解决方案，但通过适度的努力是可行的。更好地切换到 64 位时间戳（这并不绝对需要 64 位系统，顺便说一句）。

Answer 3

我假设您的嵌入式系统的 ABI 将 long 定义为 32 位。

time_t 类型不需要签名。您能做到unsigned long 并为自己和您的后代多买 68 年的安宁吗？改变这一点需要重新编译内核、C 库和所有使用time_t 的程序和库...不适合胆小的人！您不妨将其定义为long long，但这会改变许多结构布局，并且更具挑战性。