我试图在javascript中使用字符串制作Date对象,但我看到javascript解析日期字符串在这里很奇怪.
> new Date("2012-01-01");
Sun Jan 01 2012 07:00:00 GMT+0700 (ICT)
> new Date("01-01-2012");
Sun Jan 01 2012 00:00:00 GMT+0700 (ICT)
> new Date("2012-01-01") == new Date("01-01-2012")
false
Run Code Online (Sandbox Code Playgroud)
我使用Chrome 32,因为你可以看到它们有7个小时不同.请告诉我这里发生了什么?
cit*_*ave 16
这完全取决于浏览器如何实现Date.parse(规范).在传递给Date构造函数(spec)的字符串上调用该方法,并首先尝试将字符串与已知格式匹配,以确定哪些值在哪里.我希望不同的浏览器以稍微不同的方式实现该决策树,但Chrome的实现可能假定该"2012-01-01"版本是ISO-8601标准的前缀,该标准基于Zulu或GMT/UTC,并包括时区("2012-01-01T00:00:00Z-07:00")该"01-01-2012"版本是基于当地时区本地化,并没有刻意去指定它("01-01-2012 00:00:00"),所以7小时的时差是基于7小时ISO标准的日期和本地化的日期之间的偏移. 相反,Date.prototype.toString()(spec)应该显示本地时间并由Date构造函数返回,这就是为什么它在测试的两个返回值中都已本地化.
从规格 为Date.parse:
该函数首先尝试根据日期时间字符串格式(15.9.1.15)中调出的规则来解析字符串的格式.如果String不符合该格式,则该函数可以回退到任何特定于实现的启发式或特定于实现的日期格式.无法识别字符串或包含格式为String的非法元素值的日期将导致Date.parse返回NaN.
这意味着如果您不使用15.9.1.15中指定的完整ISO- 8601日期,浏览器可以在进行中或仅仅为您提供时进行补充NaN.即使这是标准,一些浏览器因为没有实际遵循标准而臭名昭着,所以您可以考虑通过自己解析数据并使用其他Date构造函数(规范)来明确指定所有参数.
| 归档时间: |
|
| 查看次数: |
976 次 |
| 最近记录: |