问题标签 [year2038]

我正在学习 Unix 高级编程中的练习，遇到了以下问题：

如果日历时间存储为带符号的 32 位整数，在哪一年会溢出？

正符号整数 = 2147483647

在以下计算中，我没有考虑闰年：

这是一种天真的方法。我怎样才能专业地解决这个问题？

堆栈成员之前提出的以下解决方案对于打印年份非常有帮助。

我在我的项目中使用 DateTime（从 UTC 到欧洲/维也纳）转换所有日期。现在我有超过 2038 的日期，并且无法获得正确的时间。

示例代码：

在 2043-03-29 和 2043-10-25 之间，由于“夏令时”，从 UTC 开始计算 +2 小时。

如果我将 2043-08-04 08:00:00 更改为 2037-08-04 08:00:00 我得到正确的时间。

我知道这是整数 32 位的 2038 问题，但是如何将整数 64 位与 DateTime setTimezone 函数一起使用？

谢谢

我正在尝试最近的std::chronoapi，我发现在 64 位 Linux 架构和 gcc 编译器上，time_point和duration类无法以最大分辨率（纳秒）处理操作系统的最大时间范围。事实上，这些类的存储似乎是 64 位整数类型，相比之下timespec，timeval它们在内部使用两个 64 位整数，一个用于秒，一个用于纳秒：

在 64 位 Windows (MSVC2017) 上情况非常相似：存储类型也是 64 位整数。在处理稳定（又名单调）时钟时这不是问题，但存储限制使不同的 API 实现不适合存储更大的日期和更宽的时间跨度，从而为类似千年虫的错误奠定了基础。问题是否得到承认？是否有更好的实施或 API 改进的计划？

我正在将一些代码从 vc120 迁移到 vc140，我遇到了 ftime64 的问题。该问题类似于Visual Studio 开发社区中提到的问题，其中 ftime64 在 2015/2017 年似乎有一个2038 年的错误，但 2013 年没有。

这是一些示例代码：

对于 2038 年 1 月 19 日 03:14:07 UTC 之后的日期，时间似乎超过了 32 位边界。

要进行测试，请将上述代码编译为 ftime_check 并从管理员命令提示符运行以下命令（请注意，您的数字会因时钟上的时间而异）：

作为参考，这里是在 vc120 下看到的（预期的）输出：

我发现所有这些函数 ftime、_ftime、_ftime64、_ftime_s 和 _ftime64_s 都存在相同的问题

有没有其他人遇到过这种情况，你是如何解决这个问题的？

由于 2038 年问题（<a href="https://en.wikipedia.org/wiki/Year_2038_problem" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Year_2038_problem），我们在 32 位机器上调用 os.time({year=2039, month=1, day=1, hour=0, sec=1}) 后得到 nil。如何使其在 lua 层兼容，并得到类似的结果在 64 位机器上运行？编写如下函数是否可行？否则怎么实现呢？

如何编写calculateDeltaTime()？

JSON Web Token是一个相当新的标准（2015 年 5 月），但他们决定使用UNIX 时间戳来表示日期。

这不会使标准暴露于各种实施中潜在的2038 年问题吗？相反，选择ISO8601之类的东西似乎更有前途。

为什么选择一个高于另一个？

我需要在 Centos 7.4 64 位上使用 php (5.4) 将日期时间信息从本地时间 (gtm+1) 转换为 UTC

我尝试了以下程序：

这一直有效到 2038 年，之后它会错误计算 DST，总是返回 1 小时的偏移量：

2037：一切正常

请注意：日期算术似乎不受 unix 时间戳（2018 年 19 月 1 日）限制的影响，因为以下表达式可以正常工作：

（打印 2118-04-23）

有什么建议么 ？问候毛里齐奥

我正在编写一段代码，即使在 2038 年之后我也想工作。我需要在地图中存储一个纪元时间戳，并且想知道当我使用 along long而不是int存储时我是否兼容，tiume(NULL)或者我最好的方法去做这件事？我知道即使使用 anunsigned int也会给 nme 更多空间 - 但这是long long最​​好的方法吗？

格林威治标准时间 2038 年 1 月 19 日 03:14:07 现在距离我们不到 20 年。这是 UNIX 的 32 位时间戳翻转的时间。我正在设计一些当时可能仍在使用的 MySQL 表。

这就是所谓的2038 年问题。

看来，从我在 MariaDB 10.3 上尝试过的东西来看，使用TIMESTAMP数据类型会在日期翻转后为日期戳产生错误 1292（不正确的日期时间值）。

将这些表设计为面向未来的良好做法是什么？我可以使用DATETIME数据，但TIMESTAMP在时区方面有一些非常有用的功能。

未来的 MySQL 版本（更不用说 Linux 和其他 UNIX 衍生产品）是否有可能升级？

也许这个问题已经问过了，但这并不能解决我的问题。

这是我在输入框中的查询，我只想显示这样的年份

提前致谢

注意：这个问题已经问过了，但它不能解决我的问题