为什么 perl 不能在 2038 年转换 unix 时间戳？答案

【问题标题】：Why perl cannot convert unix timestamp over year 2038?为什么 perl 不能在 2038 年转换 unix 时间戳？
【发布时间】：2017-01-31 19:29:14
【问题描述】：

我正在尝试使用以下 perl 命令将纪元时间转换为可读的本地时间：

       bash-3.2$ perl -le print\ scalar\ localtime\ 32503651200
       Thu Mar  9 19:13:52 1911

2038 年以下可以正确转换，但年份数大于 2038 年我无法得到预期结果。

请告知如何解决。谢谢。

【问题讨论】：

你的perl是6岁以上（5.12以上）吗？

标签： perl year2038

【解决方案1】：

32 位系统上的 year 2038 bug 是 worked around in Perl 5.12.0（64 位系统不受 2038 错误的影响）。我知道是因为I did it（在帮助下）。 :) 只需升级您的 Perl，问题（以及许多其他问题）就解决了。

或者，使用日期库，例如 DateTime。它不依赖系统时间函数（2038 漏洞的根源），不受 y2038 漏洞的影响，而且通常更易于使用。

如果您无法升级 Perl 并且必须使用 localtime 和 gmtime，您可以使用 Time::y2038 来获取不受 2038 错误影响的这些功能的版本。

【讨论】：

施韦恩，谢谢。我将提取必要性并将它们转换为 Excel。谢谢你的解释。
@Fehan Excel 和这个有什么关系？

【解决方案2】：

Year 2038 problem

2038 年问题是计算和数据存储情况的问题，其中时间值存储或计算为带符号的 32 位整数，此数字被解释为自 UTC 时间 00:00:00 以来的秒数1970 年 1 月 1 日（“纪元”）。1 这样的实现无法对 2038 年 1 月 19 日 03:14:07 UTC 之后的时间进行编码，这个问题类似于但不完全类似于“Y2K 问题”（也称为“ Millennium Bug")，其中表示自 1900 年以来的年数的 2 位数值无法对 2000 年或更晚的年份进行编码。大多数 32 位类 Unix 系统以这种“Unix 时间”格式存储和操作时间

【讨论】：

这是对问题的解释，而不是解决方法。