问题标签 [year2038]

我想我今天写的一些软件会在 30 年后使用。但我也知道，其中很多都是基于 UNIX 的传统，即自 1970 年以来将时间公开为秒数。

执行结果：

• 1970 年 1 月 1 日星期四 00:00:00
• 2008 年 8 月 30 日星期六 18:37:08
• 2038年 1 月 19 日星期二 03:14:07
• 1901 年12 月 13 日星期五 20:45:52

函数 ctime()、gmtime() 和 localtime() 都将时间值作为参数，该时间值表示自 Epoch 以来的时间（以秒为单位）（UTC 时间 00:00:00，1970 年 1 月 1 日；参见 time(3)）。

我想知道作为程序员在这方面是否有任何积极主动的事情要做，或者我们是否相信所有软件系统（又名操作系统）将来都会神奇地升级？

更新看起来确实 64 位系统是安全的：

• 1969 年 12 月 31 日星期三 16:00:00 PST
• 2008 年 8 月 30 日星期六 12:02:40 PDT
• 8 月 16 日星期六 23:12:55 PST 292278994
• 12 月 02 日星期日 08:47:04 PST 292269055

但是 292278994 年呢？

Windows 上的官方 Python 2.5 是使用 Visual Studio.Net 2003 构建的，它使用 32 位 time_t。因此，当年份 > 2038 时，它只会给出例外。

虽然这在 Python 2.6 中已修复（使用 VS2008 将 time_t 更改为 64 位），但我想使用 2.5，因为已经为它编译了许多模块。

所以这是我的问题 - 是否有任何解决方案可以轻松让我的程序处理年份 > 2038 并且仍然使用官方 Python 2.5？例如一些预制库，如"time64"或“长期”等......

请不要告诉我升级到 2.6+ 或忘记这个错误 - 我有理由需要让它工作，这就是我在这里发布问题的原因。

如何在 C 中为以下日期创建 UTC 时间：

2038 年 7 月 1 日

使用标准 ANSI C 函数调用（假设结构的tm_year元素tm不能大于 137）？

我目前正在开展一个项目，要求我们的软件必须至少运行到 2050 年。最近我们遇到了处理 NTP 协议中的 Y2.036K“错误”以及 Y2.038K 错误的问题。基本上，我们的软件必须在这些日期之后继续运行，所有数据都使用正确的时间戳记录。鉴于目前还没有解决这些错误的方法，因此必须采用变通方法。

至关重要的是，我们的软件在这两个事件之后继续运行并正确记录日期。操作系统系统时间是否正确并不重要。鉴于我们使用的是 Java，我们应该能够处理相对于 1900 年黄金时代的日期。但是，如果系统时间设置在 1970 年的 Unix 纪元之前，java JVM 甚至都不会运行！它只是崩溃。

火上浇油，NTP 服务器由另一家供应商提供，我们无法控制它。因此，使用其他协议或修改服务器来处理这些都是不可能的。

需要创造性的解决方案。不用说，必须发生一些深奥的巫术。我们考虑了以下几点：

1. 修改 ntpd 客户端软件以某种方式与 ntp 服务器协作，并从大于 1970 年而非 1900 年的 Unix 纪元的日期偏移本地时间。从而允许 JVM 运行而不会在初始化时崩溃。然后将相对于我们选择的翻转日期处理所有时间戳。（所以基本上，确保我们翻转到一个比 Unix 纪元大的日期）。

2. 让 ntp 更正时间翻转到 1900 纪元并找到修复程序，以便 JVM 不会崩溃。

有没有其他人解决过这个问题？另外，是否还有其他我没有预见到的问题，使这些解决方案中的一个或两个根本不可行？

这是一个有点异想天开的问题，部分灵感来自电影 2012的宣传，但它可能对软件系统产生真正的影响。（如果不是在 2012 年，那么肯定是在 2038 年。）

2012 年有各种各样的世界末日预测，我想知道是否有一个日期时间/时间戳系统将在 2012 年到期？（我以为我在一年前遇到过，但我不记得具体细节了。我也可能记得 2038 年。）

例如，常用的日期时间系统从 1970/1/1 开始，并从该时间开始按秒计数。如果您将 unsigned int 的最大值作为秒添加到该值，您会得到一个落在 2038 年的日期。准确地说是 2038 年 1 月 19 日凌晨 3:14:07。

那么，是否有一个日期时间系统：

纪元开始 + 常见 int 类型的最大值 = 2012 年的日期？

顺便说一句，我不想​​煽动任何偏执狂的火焰。这与实际系统设计考虑相一致。

更新甜甜圈发现此页面包含以下参考但没有更多信息：2012-07-13 Fri - UNIX time_t $50000000 at 11:01:20 UTC

有任何想法吗？

我正在考虑使用 TIMESTAMP 来存储日期+时间，但我读到它有 2038 年的限制。与其大量提出我的问题，我更愿意将其分解成小部分，以便新手用户也易于理解。所以我的问题：

1. 2038年问题到底是什么？
2. 为什么会发生以及发生时会发生什么？
3. 我们如何解决它？
4. 是否有任何可能的替代方法来使用它，而不会造成类似的问题？
5. 我们可以对使用 TIMESTAMP 的现有应用程序做些什么来避免所谓的问题，当它真正发生时？

提前致谢。

我有一个网络应用程序，它使用一个很长的时间戳来订购东西。我的网络应用程序后端恰好是用 java 编写的，所以我正在使用：

这会在哪一年（大约）失败？我的意思是，在某个时候，long 的范围会溢出，对吧？我们可能都早已死去，但我只是好奇。它会再次像 y2k 一样吗？我可以为此做些什么准备？可笑，我知道，只是好奇！

2038 年的错误遍布整个网络，但这似乎是一个 unix 问题。这将如何影响 java Date ？

我一直在阅读Y2038 问题，我知道它time_t最终会恢复为可表示的最低负数，因为它会尝试“增加”符号位。

根据该维基百科页面，time_t无法更改为无符号整数，因为它会破坏处理早期日期的程序。（这是有道理的。）

但是，我不明白为什么一开始就没有将它设为无符号整数。为什么不将 1970 年 1 月 1 日存储为零而不是一些可笑的负数？

我的理解是，由于 PHP 使用毫秒表示日期的性质，您不能表示 2038 年之后的日期。我有一个问题，我想计算很远的将来的日期。几千年后。

显然，由于限制，我不能使用 php date 函数来表示这个日期，但是，我有一些东西在我身边……我想做的就是存储年、月和日。我不关心小时、分钟、秒和毫秒。

我是否正确地认为，如果不包括这些额外的信息，我应该能够在未来进行更远的计算，因为我愿意丢弃很多信息。这是当前执行此操作的任何库吗？如果没有，对如何解决这个问题有任何建议吗？