嵌入式Linux的2038解决方案(32位)？
如何正确处理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。
我不敢相信我是唯一一个有这个问题的人，我不想重新发明轮子。
回答 3
Stack Overflow用户
发布于 2016-01-26 15:19:54
没有银弹，没有诡计，也没有聪明的解决方案。要么使用具有64位time_t的操作系统，要么不使用time_t和任何依赖它的操作系统(包括文件系统、计时器、一半网络等等)，或者计划在未来20年更新软件。
32位机器上至少有两个64位time_t的类unix系统: OpenBSD和NetBSD。OpenBSD说了几句话，解释了背后的原因：t/index.html
Stack Overflow用户
发布于 2016-01-26 14:28:20
时间转换例程将“简单地”使用2038-01-19:03:14:07Z作为Unix时间的基础，如果时间戳低于某个值。
也就是说，如果您的系统在2010-01-01年运行良好，您可以假设没有超出的时间戳低于1262300400 (这是该日期的unix时代时间)。
如果遇到较低的时间戳，请考虑它已经飞越并使用2038-01-19:03:14:07Z作为基准时间。比较也必须加以考虑。
不是一个干净的解决方案，但可以通过适度的努力完成。更好的切换到64位时间戳(这绝对不需要64位系统，顺便说一句)。
Stack Overflow用户
发布于 2016-01-26 15:00:22
我假设您的嵌入式系统的ABI将long定义为32位。
不需要对time_t类型进行签名。你能不能让它成为unsigned long，为你自己和你的后代多买68年的宁静？改变这一点需要重新编译内核、C库和所有使用time_t的程序和库.不是为了心灵的昏暗！您可以将其定义为long long，但这将改变许多结构布局，甚至更具挑战性。
https://stackoverflow.com/questions/35016003
复制相似问题
腾讯云开发者
