日期-1901年之前的年份被视为无效

11

我的系统上安装了date（GNU coreutils）7.1。

如果我尝试检查1901年12月14日之前的日期，则会收到“无效日期”错误。例如，

  $ date -d 1901-12-13
  date: invalid date `1901-12-13'

  $ date -d 1901-12-14
  Sat Dec 14 00:00:00 EST 1901

我该怎么做才能使该date实用程序在1901年之前被视为有效？

对于2038年1月19日之后的日期，我也会收到类似的错误

shell-script date

— 贾斯迪普·辛格（Jasdeep Singh）
source

我没有收到错误。我正在使用coreutils 8.10，也许是一个旧错误？

— xenoterracide 2011年

@xenoterracide您是64位系统吗？

— Mikel

@Mikel是的，我是

— xenoterracide

15

好问题。

该文件说，它应该被允许。

 info date 'Date input formats' 'Calendar date items'

对于数字月份，允许使用ISO 8601格式的“ YEAR-MONTH-DAY”，其中YEAR是任何正数，...

如果数字小于十，则必须存在前导零。

如果YEAR为68或更小，则将2000加上；否则，如果YEAR小于100，则将1900添加到其中。

您是否在32位系统上？

您是否也会在2038-01-20之后的日期出现错误，例如

date -d '2038-01-20'

如果是这样，听起来GNU日期正在使用32位时间值。

除了使用64位系统或其他工具（例如Perl中的DateTime或Python中的datetime）以外，我不确定如何解决此问题。

一些背景：

Unix时间使用整数值计算从1970年1月1日起的秒数。如果系统使用32位整数，那么它只能向前计数21亿秒（最多2038-01-19 03:14:02 UTC），向后计数21亿秒（回到1901-12-13 20:45:52世界标准时间）。

有关更多信息，请访问：

— 米克尔
source

感谢Mikel，我相信我正在使用32位计算机。实际上，我正在使用远程服务器，并且即使使用uname命令，该服务器也不会显示很多信息，除非它说它是一台i686机器，我认为这是32位机器。至于2038问题，是的，该问题实际上存在于远程服务器中。再次感谢您的输入！非常感激！！

— 2011年

是的，i686是32位的。乐意效劳。如果您需要帮助解决早于该日期的日期，请尝试我建议的Python和Perl模块，如果无法正常工作，请提出另一个问题。

— Mikel

7

您的系统（或至少是date的该版本）可能正在使用32位内部时间值。

Unix纪元（零时间值）为1970-01-01 00:00:00 UTC。此起点将1901-12-13 00:00 EST置于带符号的32位时间值的范围之外。

1901-12-14 0EST：00 EST是-2147454000
1901-12-13 15:45:52 EST是-2147483648（又名INT_MINC，最小的32位有符号整数）
1901-12-13 00:00： 00 EST是-2147540400

您可以尝试使用1901-12-13 15:45:52 EST。它应该可以工作，但是提前一秒钟可能会以与1901-12-13 00:00相同的方式失败。

— 克里斯·约翰森
source