Chrome的timeZone选项Date.toLocaleString() [英] Chrome timeZone option to Date.toLocaleString()
问题描述
我最近发现,JavaScript有一个新的扩展。这为 toLocaleString
中的 Date
对象添加了多个功能, toLocaleDateString
和 toLocaleTimeString
函数。 此处引用。
我特别感兴趣的是 timeZone
选项,它支持 IANA / Olson时区,例如 America / New_York
或欧洲/伦敦
。 目前Google Chrome仅支持此功能。
以前的建议是,要使用除UTC以外的任何其他时区或本地本地语言时区,必须使用图书馆。但现在看来,这已经开始直接融入到浏览器中。所以,现在你可以做到这一点:
new Date()。toLocaleString(en-US,{timeZone:America / New_York})
//输出:2013/7/4 5:15:45
或者:
new Date()。toLocaleString(en-NZ,{timeZone: Pacific / Chatham,
timeZoneName:long})
//输出:2013/7/5 9:59:52 GMT + 12:45
或:
timeZoneName:short})
//输出:4 / 7/2013 22:18:57 United Kingdom Time
//(奇怪的时区名称,但可以)
这是非常酷,但我有几个问题: 这是关注输出的,但我如何使用它来输入?有没有办法将构造函数中的时区传递给 两者均无效。我在规格中找不到任何东西,所以我不认为这存在(但),但是请告诉我,如果我错了。
Date
对象?我尝试了以下方法:
//用日期和时间解析它
new Date(2013-01- 01 12:34:56 America / New_York)
//将其作为命名选项传递
new日期(2013,0,1,12,34,56,{timeZone: America / New_York})
新日期(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更新?
关于API 这里< a>
这是新标准的一部分吗?也许埋在ECMAScript
6的某个地方?或者它只是Chrome的自定义功能?
是的,这些是 ECMAScript国际化API 。它与ECMAScript分开实现,但实现ECMAScript国际化API的要求是首先正确实施ECMAScript 5.1。 ?它是否支持其他地方?是否有计划
支持它在其他地方?
近年来,谷歌浏览器主要是第一个实施新特征。 Mozilla更保守,例如讨论是否实现 a
元素的下载
属性。现在可在 IE11测试版和 Opera 。它将在 Firefox 25 中提供。
我检查了使用Chrome的JavaScript运行时的node.js,但它的
在那里不起作用。为什么不呢?
node.js只使用相同的引擎,即一个单独的项目。引擎只是实现了Ecmascript 5.1。这是一个扩展node.js现在必须单独实现。它将在 Q3中的V8 中可用,因此可能稍后您可以使用它它在node.js中。
这关注于输出,但我如何使用它来输入?是否有
的方式将构造函数中的时区传递给Date对象? I
尝试了以下内容:
在规范中没有关于输入日期的信息。我个人看不出这会有用,如果你不传输UTC时间戳,你做错了,因为像2013-01-01 12:34:56 America / New_York
在从DST到标准时间的过渡期间是不明确的。
本文描述的问题由ECMAScript $即使正确的数据在
TZDB中,b $ b 5规格仍会影响输出。
这是输入问题,而不是输出。同样,用当地时区构建一个你无法影响或检测的日期是错误的。使用timestamp构造函数重载或 Date.UTC
。
我可以期待as IANA发布TZDB的更新信息,Google b $ b会推动包含更改的Chrome更新?
认为期望规则不会太落后是合理的。
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.
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.
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"
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 very cool, 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
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.
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?
update
There is pretty extensive write-up about the API here
Is this part of a new standard? Perhaps buried somewhere in ECMAScript 6? Or is it just something custom to 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
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 download
attribute of a
elements. It is now available in IE11 Beta and Opera too. It will be available in Firefox 25.
I checked node.js, which uses Chrome's JavaScript runtime, but it doesn't work there. Why not?
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.
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:
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.
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.
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
.
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.
这篇关于Chrome的timeZone选项Date.toLocaleString()的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!