javascript Date.toLocaleString() 的 Chrome 时区选项

Chrome timeZone option to Date.toLocaleString()

提问by Matt Johnson-Pint

I have recently discovered that there is a new extension to JavaScript. This adds several features to the Dateobject in the toLocaleString, toLocaleDateStringand toLocaleTimeStringfunctions. Reference here.

我最近发现 JavaScript 有一个新扩展。这Date为toLocaleString,toLocaleDateString和toLocaleTimeString函数中的对象添加了几个功能。 参考这里。

I am particularly interested in the timeZoneoption, that supports IANA/Olson time zones, such as America/New_Yorkor Europe/London. This is currently only supported in Google Chrome.

我对timeZone支持IANA/Olson 时区的选项特别感兴趣，例如America/New_York或Europe/London。 这目前仅在 Google Chrome 中受支持。

Previous advice was that to work in JavaScript with any other time zone than UTC or your own local time zone, one had to use a library. But now, it appears that this is starting to be incorporated directly into the browser. So now you can do this:

以前的建议是，要在 UTC 或您自己的本地时区以外的任何其他时区中使用 JavaScript，必须使用库. 但是现在，这似乎开始直接合并到浏览器中。所以现在你可以这样做：

new Date().toLocaleString("en-US", {timeZone: "America/New_York"})

// output: "7/4/2013 5:15:45 PM"

Or:

或者：

new Date().toLocaleString("en-NZ", {timeZone: "Pacific/Chatham",
                                    timeZoneName: "long"})

// output:  "7/5/2013 9:59:52 AM GMT+12:45"

Or:

或者：

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)

This is verycool, but I have a few questions:

这是非常酷，但我有几个问题：

• Is this part of a new standard? Perhaps buried somewhere in ECMAScript 6? Or is it just something custom to Chrome?
• Why just Google Chrome? Is it supported anywhere else? Are there plans to supported it anywhere else?
• I checked node.js, which uses Chrome's JavaScript runtime, but it doesn't work there. Why not?
• Is the time zone data accessible in any other way than the functions I listed? If only available when formatting strings, then doing any calculations based on the results may be difficult.

• This is focused on output, but how would I use it for input? Is there a way to pass the time zone in the constructor to the Dateobject? I tried the following:

  // 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"})
  

  Neither worked. I couldn't find anything in the specs, so I don't think this exists (yet), but please tell me if I am wrong.

• The issue described in this post, created by a flaw in the ECMAScript 5 spec, still affects the output, even when the correct data is in the TZDB. How is it that both old and new implementations are coexisting? One would think it would be all the old way, or all the new way. For example, with my computer's time zone set to US Eastern Time:

  new Date(2004,10,7,0,0).toLocaleString("en-US",{timeZone:"America/New_York"})
  

  returns "11/6/2004 11:00:00 PM". It should return midnight, since I started at midnight and my local time zone matches the output time zone. But it places the provided input date at the wrong UTC point due to the ES5 issue.

• Can I expect that as IANA releases updates to the TZDB that Google will push Chrome updates that contain the changes?

• 这是新标准的一部分吗？也许埋在 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 规范中的一个缺陷造成的，即使 TZD​​B 中有正确的数据，它仍然会影响输出。新旧实现如何共存？人们会认为这将是旧的方式，或所有的新方式。例如，将我的计算机时区设置为美国东部时间：

  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 更新吗？

采纳答案by Esailija

update

更新

There is pretty extensive write-up about the API here

有相当广泛的写了有关API这里

---

---

Is this part of a new standard? Perhaps buried somewhere in ECMAScript 6? Or is it just something custom to Chrome?

这是新标准的一部分吗？也许埋在 ECMAScript 6 的某个地方？或者它只是 Chrome 的自定义内容？

Yes, these are part of the ECMAScript Internationalization API. It is implemented separate from ECMAScript, but the requirement of implementing ECMAScript Internationalization API is to first have correct implementation of ECMAScript 5.1

是的，这些是ECMAScript 国际化 API 的一部分。它是独立于 ECMAScript 实现的，但实现 ECMAScript 国际化 API 的要求是首先正确实现 ECMAScript 5.1

Why just Google Chrome? Is it supported anywhere else? Are there plans to supported it anywhere else?

为什么只有谷歌浏览器？其他地方是否支持？是否有计划在其他地方支持它？

For the recent years, Google Chrome has mostly been first to implement new features. Mozilla is more conservative, still for example discussing whether to implement the downloadattribute of aelements. It is now available in IE11 Betaand Operatoo. It will be available in Firefox 25.

近年来，谷歌浏览器大多是第一个实现新功能的人。Mozilla 比较保守，比如还在讨论是否实现元素的download属性a。它现在也可用于IE11 Beta和Opera。它将在Firefox 25 中可用。

I checked node.js, which uses Chrome's JavaScript runtime, but it doesn't work there. Why not?

我检查了 node.js，它使用 Chrome 的 JavaScript 运行时，但它在那里不起作用。为什么不？

node.js just uses the same engine, which is a separate projectfrom the Google Chrome browser. The engine just implements Ecmascript 5.1. This is an extension node.js would have to implement separately right now. It will become available in V8 in Q3so probably a bit after that you can use it in node.js.

node.js 只是使用相同的引擎，这是一个独立于 Google Chrome 浏览器的项目。该引擎仅实现了 Ecmascript 5.1。这是 node.js 现在必须单独实现的扩展。它将在第三季度在V8 中可用，所以可能之后你可以在 node.js 中使用它。

This is focused on output, but how would I use it for input? Is there a way to pass the time zone in the constructor to the Date object? I tried the following:

这侧重于输出，但我将如何将其用于输入？有没有办法将构造函数中的时区传递给 Date 对象？我尝试了以下方法：

There is nothing about inputting dates in the specification. I personally cannot see how this would be useful, you are doing it wrong if you are not transmitting UTC timestamps because something like "2013-01-01 12:34:56 America/New_York"is ambiguous during transitions from DST to standard time.

规范中没有关于输入日期的内容。我个人看不出这会有什么用处，如果您不传输 UTC 时间戳，您就做错了，因为"2013-01-01 12:34:56 America/New_York"在从 DST 到标准时间的转换过程中，类似的事情是不明确的。

The issue described in this post, created by a flaw in the ECMAScript 5 spec, still affects the output, even when the correct data is in the TZDB.

这篇博文中描述的问题是由 ECMAScript 5 规范中的一个缺陷造成的，即使 TZD​​B 中的数据正确，它仍然会影响输出。

This is input issue, not output. Again, constructing a date with local timezone that you cannot influence or detect is doing it wrong. Use the timestamp constructor overload or Date.UTC.

这是输入问题，而不是输出问题。同样，使用您无法影响或检测到的本地时区构建日期是错误的。使用时间戳构造函数重载或Date.UTC.

Can I expect that as IANA releases updates to the TZDB that Google will push Chrome updates that contain the changes?

我可以期待随着 IANA 向 TZDB 发布更新，Google 会推送包含这些更改的 Chrome 更新吗？

Nothing in the spec but I think it will be reasonable to expect that the rules are not too much behind.

规范中没有任何内容，但我认为期望规则不会落后太多是合理的。

回答by Antti Haapala

Is this part of a new standard? Perhaps buried somewhere in ECMAScript 6? Or is it just something custom to Chrome?

这是新标准的一部分吗？也许埋在 ECMAScript 6 的某个地方？或者它只是 Chrome 的自定义内容？

Indeed it is part of the new ECMA-402 standard. The standard is very difficult to read, but there is this friendly introduction.

事实上，它是新 ECMA-402 标准的一部分。该标准很难阅读，但有这个友好的介绍。

Why just Google Chrome? Is it supported anywhere else? Are there plans to supported it anywhere else?

为什么只有谷歌浏览器？其他地方是否支持？是否有计划在其他地方支持它？

MDN has a list of supporting browsers. According to Bug 853301it will be available in Firefox 25.

MDN 有一个支持浏览器的列表。根据Bug 853301，它将在 Firefox 25 中可用。

I checked node.js, which uses Chrome's JavaScript runtime, but it doesn't work there. Why not?

我检查了 node.js，它使用 Chrome 的 JavaScript 运行时，但它在那里不起作用。为什么不？

Possible reasons are many; it is not up to the current code base, or it would make the node.js bigger and slower (the previous bug tracker entry from Mozilla indicates that the timezone data increased the download size of Firefox by 10 %, and caused the I/O to increase substantially during browser start up.

可能的原因有很多；不符合当前的代码库，否则会使 node.js 变大变慢（Mozilla 之前的 bug tracker 条目表明时区数据使 Firefox 的下载大小增加了 10%，并导致 I/O在浏览器启动期间大幅增加。

Is the time zone data accessible in any other way than the functions I listed? If only
available when formatting strings, then doing any calculations based on the results may be difficult.

时区数据是否可以通过我列出的函数以外的任何其他方式访问？如果仅
在格式化字符串时可用，则根据结果进行任何计算可能会很困难。

Seems that it is not available. Furthermore, the Intl API primer talks that only UTC and local time zone are absolutely required to be supported.

似乎它不可用。此外，Intl API 入门说只有 UTC 和本地时区是绝对需要支持的。

This is focused on output, but how would I use it for input? Is there a way to pass the time zone in the constructor to the Date object? I tried the following:

这侧重于输出，但我将如何将其用于输入？有没有办法将构造函数中的时区传递给 Date 对象？我尝试了以下方法：

The Intl API only speaks about date/time formatting, string collations and number formatting. The datetime formatting not only supports the Gregorian calendar but also many kinds of other calendars, lunar, lunisolar and so forth.

Intl API 只讨论日期/时间格式、字符串排序规则和数字格式。日期时间格式不仅支持公历，还支持多种其他日历，农历、阴历等。

The issue described in this post, created by a flaw in the ECMAScript 5 spec, still affects the output, even when the correct data is in the TZDB. How is it that both old and new implementations are coexisting? One would think it would be all the old way, or all the new way. For example, with my computer's time zone set to US Eastern Time:

new Date(2004,10,7,0,0).toLocaleString("en-US",{timeZone:"America/New_York"})

returns "11/6/2004 11:00:00 PM". It should return midnight, since I started at midnight and > my local time zone matches the output time zone. But it places the provided input date at the > wrong UTC point due to the ES5 issue.

这篇博文中描述的问题是由 ECMAScript 5 规范中的一个缺陷造成的，即使 TZD​​B 中的数据正确，它仍然会影响输出。新旧实现如何共存？人们会认为这将是旧的方式，或所有的新方式。例如，将我的计算机时区设置为美国东部时间：

new Date(2004,10,7,0,0).toLocaleString("en-US",{timeZone:"America/New_York"})

返回“11/6/2004 11:00:00 PM”。它应该返回午夜，因为我从午夜开始并且 > 我的本地时区与输出时区匹配。但由于 ES5 问题，它将提供的输入日期置于 > 错误的 UTC 点。

The reason for that is that ES5 mandates that the input to new Date be calculated using the current DST and offset, that is it is America/New York but with EDT timezone, even though Nov 6 is not in EDT. Obviously as this is so specified, then it cannot be changed. However, as Chrome is using the TZDB to do the conversion from the bare UTC point-in-time value to the America/New York tz, it then does consider the time as being in EST.

这样做的原因是 ES5 要求使用当前 DST 和偏移量计算新日期的输入，即美国/纽约但使用 EDT 时区，即使 11 月 6 日不在 EDT 中。显然，由于这是如此指定的，因此无法更改。但是，由于 Chrome 正在使用 TZDB 进行从原始 UTC 时间点值到 America/New York tz 的转换，因此它确实将时间视为在 EST 中。

Can I expect that as IANA releases updates to the TZDB that Google will push Chrome updates that contain the changes?

我可以期待随着 IANA 向 TZDB 发布更新，Google 会推送包含这些更改的 Chrome 更新吗？

I'd believe so

我会相信