为什么JavaScript可以处理超过2038年的时间戳?

Par*_*med 6 javascript php

我们知道使用Javascript Date构造函数的所有日期都是从世界时间01月1日1970年00:00:00(世界时)(UTC)开始的毫秒数,其中包含86,400,000毫秒的日期.这意味着JS使用UNIX时间戳.我将我的计时器设置为2038年以后的日期(比如2039年11月14日)并运行脚本:

    <script>
      var d = new Date();
      alert(d.getFullYear()+" "+d.getMonth()+" "+d.getDate());
    </script>
Run Code Online (Sandbox Code Playgroud)

它成功警告2039 10 14不像PHP打印"9 Oct,1903 07:45:59"

JS如何处理这个?感到很困惑,我很感激!

dec*_*eze 11

32位PHP使用32位整数,其最大值放在2038年可以表示的最后一个UNIX时间戳.这就是众所周知的Y2K38问题,几乎影响所有使用UNIX时间戳的32位软件.移动到64位或与其他时间戳表示一起使用的库(在PHP DateTime类的情况下)解决了这个问题.

Javascript没有整数,只有浮点数,它没有固有的最大值(但反过来精度较低).

  • @Alex因为这样你就不能代表1970年*之前*的任何日期,因为PHP试图保持类型简单并且不想让程序员担心有符号和无符号整数之间的差异,因为*仅*无符号整数意味着你不能不代表 PHP 中的*任何*负数,因为这只会将截止日期延长大约 70 年,而不是完全解决它。 (3认同)

Jon*_*son 5

Javascript 没有整数,只有浮点数(详细信息可以在标准文档中找到)。

这意味着您可以表示一些非常大的数字,但要以精度为代价。一个简单的测试是这样的:

i = 1384440291042
 => 1384440291042
i = 13844402910429
 => 13844402910429
i = 138444029104299
 => 138444029104299
i = 1384440291042999
 => 1384440291042999
i = 13844402910429999
 => 13844402910430000
i = 138444029104299999
 => 138444029104300000
i = 1384440291042999999
 => 1384440291043000000
i = 13844402910429999999
 => 13844402910430000000
Run Code Online (Sandbox Code Playgroud)

如您所见,不能保证该数字保持准确。javascript 中整数精度的外部限制(你实际上会得到你输入的相同值)是 9007199254740992。根据我的转换测试,直到 285428751-11-12T07:36:32+00:00 为止都很好: )

简单的答案是 Javascript 在内部使用比用于 C 风格 epoc 的 longint(4 字节,32 位)更大的数据类型......