我们知道使用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没有整数,只有浮点数,它没有固有的最大值(但反过来精度较低).
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 位)更大的数据类型......