time - Linux 时钟会在 2038 年 1 月 19 日 3:14:08 失效吗？

问题描述

我有点担心这个。这就是所谓的“2038年问题”。从 12.04 开始，Linux 内核或 Ubuntu 是否已准备好处理此后的日期？

最佳思路

不，它不会失败。在最坏的情况下，从程序员的角度来看，它将按预期工作：将重置为日期 1901-12-13 20:45:52：

以防万一，在这种情况发生之前，您不会更新当前的发行版。 “更新很容易。其中一个更新肯定会包含修复程序。”就像 chocobai 说的。

我记得在 2000 年之前的 16 位机器上是同样的问题/问题，最后它没有任何问题。

来自维基百科的解决方案：

Most operating systems designed to run on 64-bit hardware already use signed 64-bit time_t integers. Using a signed 64-bit value introduces a new wraparound date that is over twenty times greater than the estimated age of the universe: approximately 292 billion years from now, at 15:30:08 on Sunday, 4 December 292,277,026,596. The ability to make computations on dates is limited by the fact that tm_year uses a signed 32 bit int value starting at 1900 for the year. This limits the year to a maximum of 2,147,485,547 (2,147,483,647 + 1900). While this solves the problem for executing programs, it does not solve the problem of storing date values within binary data files, many of which employ rigid storage formats. It also doesn’t solve the problem for 32-bit programs running under compatibility layers and may not solve the problem for programs that incorrectly store time values in variables of types other than time_t.

我在 64 位上使用 Ubuntu 13.04，出于好奇，我手动将时间更改为 2038-01-19 03:13:00。 03:14:08 之后什么也没发生：

所以这个问题没什么好担心的。

更多关于：

次佳思路

您可以使用以下 Perl 脚本检查计算机的时间是否会崩溃：

#!/usr/bin/perl
use POSIX;
$ENV{'TZ'} = "GMT";
for ($clock = 2147483641; $clock < 2147483651; $clock++) {
    print ctime($clock);
}

如果你的电脑没问题，你会得到这个：

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038       <-- Last second in 32-bit Unix systems
Tue Jan 19 03:14:08 2038
Tue Jan 19 03:14:09 2038
Tue Jan 19 03:14:10 2038

如果你的电脑和我的一样，它会像这样环绕：

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901

它也可以这样做：

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038

第三种思路

我在 1996 年写并发表了一篇关于此的简短论文。其中包括一个简短的 C 程序来演示它。我还与 David Mills 就 NTP(网络时间协议)的类似问题发送了电子邮件。在我的 Ubuntu 14.04 64 位笔记本电脑上，perl 代码没有显示出限制，因此必须修改了底层 64 位库。

但是，运行我的 long-ago 测试代码确实显示时间回溯到 UNIX Epoch。因此，过去的 32 位代码并非一切都很好。

我 1996 年的论文 The UNIX time will run out in 2038! 从 2000 年左右开始出现在我的网站上。这个标题为 “UNIX Time” 的变体于 1998 年发表在“Y2K Millennium Computing 的 2000 年最佳实践”ISBN 0136465064 中。

参考资料

Will the Linux clock fail at January 19, 2038 3:14:08?