我最近发现JavaScript有一个新的扩展。这为toLocaleString、toLocaleDateString和toLocaleTimeString函数中的Date对象添加了几个特性。此处引用。
我对timeZone选项特别感兴趣，它支持IANA/Olson时区，如America/New_York或Europe/London这目前仅在Google Chrome中受支持。
以前的建议是，要在UTC或您自己的本地时区之外的任何其他时区使用JavaScript，必须使用库。但现在，它似乎开始直接融入浏览器。所以现在你可以这样做了：
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的自定义功能
- 为什么只有谷歌浏览器？其他地方支持它吗？有计划在其他地方支持它吗
- 我检查了node.js，它使用Chrome的JavaScript运行时，但在那里不起作用。为什么不呢
- 时区数据是否可以通过我列出的功能之外的任何其他方式访问？如果仅在格式化字符串时可用，那么根据结果进行任何计算都可能很困难
这集中在输出上，但我该如何使用它进行输入呢？有没有办法将构造函数中的时区传递给
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"})返回CCD_ 9。它应该在午夜返回，因为我在午夜开始，并且我的本地时区与输出时区匹配。但由于ES5问题，它将提供的输入日期放置在错误的UTC点。
我能指望随着IANA向TZDB发布更新，谷歌会推送包含更改的Chrome更新吗？
更新
这里有大量关于API的文章
这是新标准的一部分吗？也许埋在ECMAScript的某个地方6.或者它只是Chrome的自定义功能？
是的，这些是ECMAScript国际化API的一部分。它是与ECMAScript分开实现的，但实现ECMAScript国际化API的要求是首先要有正确的ECMAScript5.1 实现
为什么只有谷歌浏览器？其他地方支持它吗？有计划吗在其他地方支持它？
最近几年，谷歌浏览器大多是第一个实现新功能的。Mozilla更为保守，例如仍在讨论是否实现a元素的download属性。它现在可以在IE11测试版和Opera中使用。它将在Firefox 25中提供。
我检查了node.js，它使用Chrome的JavaScript运行时，但它在那里不起作用。为什么不呢？
node.js只是使用了相同的引擎，这是一个独立于Google Chrome浏览器的项目。该引擎只实现了Ecmascript 5.1。这是node.js现在必须单独实现的扩展。它将在第三季度的V8中提供，所以可能在那之后你可以在node.js.中使用它
这集中在输出上，但我该如何使用它进行输入呢？有吗将构造函数中的时区传递给Date对象的方法？我尝试了以下操作：
规范中没有关于输入日期的内容。我个人看不出这会有什么用处，如果你不传输UTC时间戳，那你就错了，因为像"2013-01-01 12:34:56 America/New_York"这样的东西在从夏令时到标准时间的转换过程中是不明确的。
本文中描述的问题是由ECMAScript中的一个缺陷造成的5规范，即使在TZDB。
这是输入问题，而不是输出问题。同样，用当地时区构建一个你无法影响或检测的日期是错误的。使用时间戳构造函数重载或Date.UTC。
我能期待IANA发布谷歌对TZDB的更新吗会推送包含更改的Chrome更新吗？
规范中没有任何内容，但我认为期望规则不会落后太多是合理的。
这是新标准的一部分吗？也许埋在ECMAScript的某个地方6.或者它只是Chrome的自定义功能？
事实上，它是新ECMA-402标准的一部分。标准很难阅读，但有一个友好的介绍。
为什么只有谷歌浏览器？其他地方支持它吗？有计划吗在其他地方支持它？
MDN有一个支持浏览器的列表。根据Bug 853301，它将在Firefox 25中提供。
我检查了node.js，它使用Chrome的JavaScript运行时，但在那里不起作用。为什么不呢？
可能的原因有很多；它不符合当前的代码库，否则会使node.js变得更大、更慢（Mozilla之前的错误跟踪条目表明，时区数据使Firefox的下载量增加了10%，并导致浏览器启动期间I/O大幅增加。
时区数据是否可以通过我列出的功能之外的任何其他方式访问？如果只是
格式化字符串时可用，然后根据结果进行任何计算可能困难的
似乎没有。此外，Intl API初级演讲指出，只有UTC和本地时区是绝对需要支持的。
这集中在输出上，但我该如何使用它进行输入呢？有路可以通过吗构造函数中Date对象的时区？我尝试了以下方法：
Intl API仅介绍日期/时间格式、字符串排序规则和数字格式。日期时间格式不仅支持公历，还支持许多其他日历，如农历、阴阳月等。
这篇文章中描述的问题是由ECMAScript 5规范中的一个缺陷造成的，它仍然影响输出，即使TZDB中有正确的数据。旧的和新的是怎么回事实现是共存的？人们会认为这将是一种古老的方式，或者是全新的方式方法例如，我的电脑时区设置为美国东部时间：
new Date（2004,10,7,0,0）.toLocaleString（"en-US"，｛timeZone:"America/new_York"｝）
return"11/6/2004 11:00:00 PM"。它应该在午夜返回，因为我在午夜开始，并且>我的本地时区与输出时区匹配。但由于ES5问题，它将提供的输入日期放置在>错误的UTC点。
原因是ES5要求使用当前夏令时和偏移量计算新日期的输入，也就是说，它是美国/纽约，但有美国东部时间时区，即使11月6日不在美国东部时间。显然，由于这是如此指定，因此它不能更改。然而，由于Chrome使用TZDB将原始UTC时间值转换为美国/纽约时间，因此它确实认为时间在EST中。
我能指望随着IANA发布TZDB的更新，谷歌会推送Chrome更新吗包含更改的？
我相信