问题标签 [year2038]

php 函数time();在 2038 年之后会起作用吗？

我刚刚发现，运行日历脚本，PHP 中的时间戳限制为 2038。这到底是什么意思？为什么是 2038 而不是 2050 或 2039？如果时间戳只计算给定日期（1970 年）的秒数，为什么要限制？

可能重复：
我们应该为 2038 年做些什么准备？

什么是 2038 年问题？

如何找出我们的代码是否有这个问题并解决它？

我在 Android 应用程序中向数据库 H2 插入日期，当日期大于 2038 年 1 月 19 日（Unix 年 2038 错误）时，保存到数据库的日期会根据 android 设备的时区而变化。

示例：日期 2050-12-31

• 时区 +2:00 埃尔开罗保存 2050-12-29（错误）
• 时区 +2:00 阿姆斯特丹保存 2050-12-30（错误）
• 时区 +2:00 布鲁塞尔保存 2050-12-31 (OK)
• 日本时区保存 2050-12-31 (OK)
• 中国时区保存2050-12-31（OK）
• 亚速尔群岛时区保存 2050-12-31 (OK)

我想使用 android 的 Linux 内核有 2038 年的错误，但我不明白在某些情况下它可以正常工作而在其他情况下不能正常工作的原因。

这个问题有什么解决办法吗？java.util.Date在 Android 中使用安全吗？

我有一些代码用于将存储为字符串的一些时间戳转换为日期时间对象，并注意到今天在转换具有大于最大 int 的 int 时间戳值的日期时出现异常。

例如给我

我怎样才能解决这个问题？假设我想继续使用 32 位 python（运行 2.7.2）

我注意到我可以将 max int 转换为 datetime 对象，然后使用 timedeltas 添加任何额外的内容，但在实践中我想不出一种特别有效或好的方法。我可以将这些 2038+ 时间戳转换为日期时间对象的好方法是什么？

我想打印或提取年/月/日值。

因为2038年的问题我不想用time_t，但是我在网上找到的所有例子都用它转换time_point成tm.

有没有一种简单的方法可以从 time_point 转换为 tm （最好没有 boost）？

像libc中的timesub这样的实现将是我最后的选择： http ://www.opensource.apple.com/source/Libc/Libc-262/stdtime/localtime.c

编辑：阅读建议的链接并进行更多研究后，我得出以下结论。

1. 使用 64 位长的 time_t 是可以的（对于大多数目的）。
2. 将 Boost.Date_Time 用于可移植代码。

值得注意的是 Boost.Date_Time 可以是一个只有头文件的库。来源： http: //www.boost.org/doc/libs/1_53_0/more/getting_started/unix-variants.html#header-only-libraries

我需要显示四个参数来显示年份和期间之间的数据，例如我想返回发生在 2011 年期间 12 和 2012 年期间 4 之间的交易

我已经走了这么远，但不知道把我放在哪里，我想我还需要 <= 或 >= 某处？

我正在尝试创建一个接受 mm/yy 的文本框。出于某种原因，这不喜欢 2032 年以后的日期。谁能告诉我为什么不这样做以及解决方案是什么？

更新：问题似乎严格来说是一个 2 位数的年份问题。

如果有任何不同，以下信息可能会有所帮助：

• 使用 Dojo 1.8
• 这是小部件模板的一部分
• 对此小部件进行了 postCreate 修改，以将 fullYear 约束设置为 false。
• 它不使用标准的弹出日历，并且无论是通过弹出窗口还是文本框输入日期都没有关系。
• 该问题似乎严格来说是一个 2 位数的年份格式问题 - 当日期格式更改为 MM/yyyy 并且 fullYear 为真时，它工作正常。

我不想再开始讨论使用DATETIMEvs TIMESTAMPvs之间的赞成或反对INT。（我已经阅读过使用 MySQL 的 TIMESTAMP 与直接存储时间戳之类的文章。）

我有时使用INT数据类型将 unix 时间戳存储在数据库中。这是因为我的应用程序中的日期和时间计算通常使用 unix 时间戳完成（例如会话超时和令牌到期）。DATETIME此外，当我可以WHERE简单地比较子句中的整数值时，数据库中的数据选择比使用更快。很少有表有 10+ 百万行（最多 1 亿行），这 4 个字节也真正节省了存储空间（在磁盘和内存中，因为索引更小）。

关于 Y2K38 问题，我假设（并希望如此），UNIX_TIMESTAMP在 MySQLtime()中的 PHP 将在未来返回 64 位值，因此无需更改应用程序本身的某些内容。关键是，我在 MySQL 中将所有这些伪整数时间戳存储为无符号整数（我的意思是INT不是BIGINT）。当然，无符号整数时间戳会在 2106 年溢出，但这比 2038 年要多一点时间。

我现在的问题是：假设它UNIX_TIMESTAMP本身将在 2038 年之后工作，那么在 2106 年之前，当这些时间戳在 MySQL 中存储为无符号整数时，MySQL 和/或 PHP 中是否存在任何问题？（请不要争论：到2038年之前会有很多时间来解决这个问题，我想从不再触及应用程序的角度来澄清这一点）

编辑：因为问题出现了：我只在这些列中存储当前时间戳，没有出生日期，没有未来日期。只有当前的时间戳，所以我想澄清这是否会在 2038 年之后起作用。

我刚刚意识到 2038 年的问题，当 unix 时间将重置为负最小范围时，所以我决定对这个有趣的话题进行一些研究。

现在我正在设计数据库的结构（在 mysql 中），我认为这两个考虑因素可能会解决问题：

1) - 不是将时间数据存储在时间戳字段中，而是存储在 bigint（或更大）列中。

2) - 我将用于我的应用程序的服务器使用 64 位操作系统，因此如果我使用 php date 函数，它将正确返回日期。

基于我即将接受使用时间戳的这些考虑，您对此有何看法？谢谢..