2038年嵌入式Linux（32位）解决方案？

Question

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

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

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

我无法相信我是唯一有这个问题的人，我不想重新发明轮子。

Answer 1

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

即。如果您的系统在2010-01-01中生效，您可以假设没有溢出的时间戳低于1262300400（这是该日期的unix纪元时间）。

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

不是一个干净的解决方案，但可以适度努力。最好切换到64位时间戳（不一定需要64位系统，顺便说一句）。

Answer 2

没有银子弹，技巧或聪明的解决方案。使用具有64位time_t或不使用time_t的操作系统以及依赖于它的任何操作系统（包括文件系统，计时器，网络的一半等）或计划更新软件在未来20年。

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

Answer 3

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

无需签署time_t类型。你能否做到unsigned long并为自己和你的后代买一个额外的68年的宁静？更改此内容需要重新编译内核，C库以及使用time_t的所有程序和库...不适合胆小的人！您也可以将其定义为long long，但这会改变许多结构布局，甚至更具挑战性。