距 2038 只剩 21 年，开源软件社区正着手应对之策

距离 2038 年还有 21 年，这听起来似乎还有很长一段时间，但对于许多生命周期相对较长的嵌入式系统来说，现在部署的系统到该期限时仍然会投入使用，因此也该提前做好打算了。

2038 年问题是指使用 POSIX 时间的 32 位计算机应用程序，将在格林尼治时间 2038 年 1 月 19 日凌晨03:14:07（北京时间：2038 年 1 月 19 日中午 11:14:07）之后无法正常工作。因为它们的时间起点是格林尼治时间 1970 年 1 月 1 日 0 时 0 分 0 秒（这个时间名叫 the Unix Epoch），它们用 the Unix Epoch 经过的秒数（忽略闰秒）来表示时间。这种时间表示法在类 Unix（Unix-like）操作系统上是一个标准，并会影响以其 C 编程语言开发给其他大部份操作系统使用的软件。在大部分的 32 位操作系统上，此 “time_t” 数据模式使用一个有符号 32 位整数(signed int32)存储计算的秒数。依照此 “time_t” 标准，在此格式能被表示的最后时间是第2147483647秒（代表格林尼治时间2038年1月19日凌晨03:14:07）。下一秒，即格林尼治时间2038年1月19日凌晨03:14:08，由于32位整型溢出，时间将会被“绕回”（wrap around）成一个负数，变成了第 -2147483648 秒（代表格林尼治时间1901年12月13日20:45:52），造成应用程序发生严重的时间错误，而无法运行。

为了应对 2038 年问题，正带队努力解决这个问题的开发者之一 Arnd Bergmann 在 Linaro Connect 2017 大会上，表示开源自由软件社区正在三个不同的方面进行努力：

一、内核方面：将 32 位时间戳转变成 64 位值，即使在 32 位系统上也同样如此。但一些 32 位时间戳出现在用户空间 API 中，使得问题比较复杂；
二、C 代码库：glibc 社区正在着手做这方面的工作，目标是实现完全的向后兼容，让程序在旧的内核上能使用 64 位时间戳，最小化干扰；
三、发行版版本分配：大多数发行版到 2038 年不太可能还需要考虑 32 位系统，所以不用太过担心。唯独 Debian 可能是例外，似乎有兴趣维持支持。但它可能需要在某个时刻进行全面重构，这其实并不有趣，但它至少是一个已知的工作过程。