我最近发现了一种新的JavaScript扩展。它为toLocaleString
、toLocaleDateString
和toLocaleTimeString
函数添加了一些特性,这些特性是针对Date
对象的。参考链接在这里。
我特别感兴趣的是timeZone
选项,它支持IANA/Olson时区,例如America/New_York
或Europe/London
。目前只有Google Chrome支持该选项。
以前的建议是,如果要在JavaScript中使用UTC或其他时区而不是本地时区,则必须使用库。但现在,它似乎开始直接整合到浏览器中了。因此,现在你可以这样做:
new Date().toLocaleString("en-US", {timeZone: "America/New_York"})
// output: "7/4/2013 5:15:45 PM"
或者:
new Date().toLocaleString("en-NZ", {timeZone: "Pacific/Chatham",
timeZoneName: "long"})
// output: "7/5/2013 9:59:52 AM GMT+12:45"
或者:new Date().toLocaleString("en-GB", {timeZone: "Europe/London",
timeZoneName: "short"})
// output: "4/7/2013 22:18:57 United Kingdom Time"
// (strange time zone name, but ok)
这很酷,但我有几个问题:
- 这是一个新标准的一部分吗?可能是ECMAScript 6中的某个隐藏功能吗?还是只是Chrome自定义的东西?
- 为什么只限于Google Chrome?它在其他地方也受支持吗?是否有计划在其他地方支持它?
- 我检查了使用Chrome JavaScript运行时的node.js,但在那里不起作用。为什么?
- 除了我列出的函数之外,是否以其他方式可以访问时区数据?如果仅在格式化字符串时可用,则基于结果进行任何计算可能会很困难。
这关注的是输出,但我如何将其用于输入?有没有办法将时区传递给
Date
对象的构造函数?我尝试了以下操作:
// parsing it with a date and time
new Date("2013-01-01 12:34:56 America/New_York")
// passing it as a named option
new Date(2013,0,1,12,34,56,{timeZone:"America/New_York"})
两种方法都没有奏效。我在规范中找不到任何内容,因此我认为这种情况不存在(尚未出现),但如果我错了,请告诉我。
在这篇文章中描述的问题由ECMAScript 5规范中的缺陷引起,即使TZDB中有正确的数据,该问题仍会影响输出。为什么新旧实现都能共存呢?人们可能会认为应该全部采用旧方式或新方式。例如,将我的计算机时区设置为美国东部时间:
new Date(2004,10,7,0,0).toLocaleString("en-US",{timeZone:"America/New_York"})
返回"11/6/2004 11:00:00 PM"
。由于我在午夜开始并且我的本地时区与输出时区匹配,所以它应该返回午夜。但由于ES5问题,它将提供的输入日期放在了错误的UTC点。
我能期望随着IANA发布TZDB更新,Google会推送包含更改的Chrome更新吗?
new Date(2013,2,10,2,30)
- Chrome 将其倒回到1:30,而IE将其推进到3:30。最好的实现将采用本地时间、时区和偏移量。因此,一个完全明确的输入可能是类似于new Date("2013-11-03T01:00:00-04:00","America/New_York")
的东西。 - Matt Johnson-PintOption value 'AMERICA/NEW_YORK' for 'timeZone' is outside of valid range. Expected: ['UTC']
。 - Matt Johnson-Pint