Chrome的timeZone选项Date.toLocaleString() [英] Chrome timeZone option to Date.toLocaleString()

查看:491
本文介绍了Chrome的timeZone选项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
//(奇怪的时区名称,但可以)

这是非常酷,但我有几个问题:


  • 这部分是新标准?也许埋在ECMAScript 6的某个地方?或者它只是Chrome的自定义功能?

  • 为什么只使用Google Chrome?它是否支持其他地方?是否有计划在其他地方支持它?

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

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

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

      //用日期和时间解析它
    new Date(2013-01- 01 12:34:56 America / New_York)

    //将其作为命名选项传递
    new日期(2013,0,1,12,34,56,{timeZone: America / New_York})

    两者均无效。我在规格中找不到任何东西,所以我不认为这存在(但),但是请告诉我,如果我错了。

  • 此文章中描述的问题(由ECMAScript 5规范中的缺陷创建)仍然会影响输出,即使正确的数据在TZDB中。新旧实现如何共存?人们会认为这将是所有旧的方式,或全新的方式。例如,将我的电脑的时区设为美国东部时间:

     新日期(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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆