Date.toLocaleString() 的 Chrome 时区选项

问题描述

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

I have recently discovered that there is a new extension to JavaScript. This adds several features to the Date object in the toLocaleString, toLocaleDateString and toLocaleTimeString functions. Reference here.

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

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

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

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:

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)

这非常很酷，但我有几个问题:

This is very cool, but I have a few questions:

• 这是新标准的一部分吗?也许埋在 ECMAScript 6 的某个地方?还是它只是 Chrome 的自定义功能?
• 为什么只使用谷歌浏览器?它在其他任何地方都支持吗?是否有计划在其他任何地方支持它?
• 我检查了使用 Chrome 的 JavaScript 运行时的 node.js，但它在那里不起作用.为什么不呢?
• 是否可以通过我列出的函数以外的任何其他方式访问时区数据?如果仅在格式化字符串时可用，那么根据结果进行任何计算可能会很困难.

• 这是专注于输出，但我如何将它用于输入?有没有办法将构造函数中的时区传递给 Date 对象?我尝试了以下方法:

• 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 Date object? 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.

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

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

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

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.

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

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

推荐答案

更新

这里

这是新标准的一部分吗?也许埋在 ECMAScript 的某个地方6?还是只是 Chrome 的自定义功能?

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

是的，这些是 ECMAScript Internationalization API 的一部分.它与 ECMAScript 分开实现，但实现 ECMAScript 国际化 API 的要求是首先正确实现 ECMAScript 5.1

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

为什么只有谷歌浏览器?它在其他任何地方都支持吗?有没有计划在其他任何地方都支持它?

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

近年来，谷歌浏览器大多率先实施新功能.Mozilla 比较保守，比如还在讨论是否实现 a 元素的 download 属性.它现在在 IE11 Beta 和Opera.它将在 Firefox 25 中提供.

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 download attribute of a elements. It is now available in IE11 Beta and Opera too. It will be available in Firefox 25.

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

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

node.js 只是使用相同的引擎，它是与 Google Chrome 浏览器一个单独的项目.该引擎只实现了 Ecmascript 5.1.这是一个扩展 node.js 现在必须单独实现.它将在 V8 in Q3 中可用，因此可能稍后您可以使用它在 node.js 中.

node.js just uses the same engine, which is a separate project from 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 Q3 so probably a bit after that you can use it in node.js.

这专注于输出，但我将如何将其用于输入?在那儿将构造函数中的时区传递给 Date 对象的方法?一世尝试了以下方法:

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:

没有关于在规范中输入日期的内容.我个人看不出这会有什么用，如果你不传输 UTC 时间戳，你就做错了，因为像 "2013-01-01 12:34:56 America/New_York" 这样的东西在从 DST 转换到标准时间.

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.

这篇文章中描述的问题是由 ECMAScript 中的一个缺陷造成的5 规格，仍然会影响输出，即使正确的数据在TZDB.

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.

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

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.

我可以期待随着 IANA 发布对 TZDB 的更新，Google是否会推送包含更改的 Chrome 更新?

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

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

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

这篇关于Date.toLocaleString() 的 Chrome 时区选项的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！