web-dev-qa-db-ja.com

Chrome Date.toLocaleString（）へのtimeZoneオプション

私は最近、JavaScriptに新しい拡張機能があることを発見しました。これにより、Date、toLocaleString、およびtoLocaleDateString関数のtoLocaleTimeStringオブジェクトにいくつかの機能が追加されます。 ここを参照 。

私は特にtimeZoneオプションに興味があり、America/New_YorkやEurope/Londonなどの IANA/Olsonタイムゾーン をサポートしています。 これは現在、Google Chromeでのみサポートされています。

以前のアドバイスは、JavaScriptでUTCまたは独自のローカルタイムゾーン以外のタイムゾーンで作業するには、 ライブラリを使用 する必要があったということです。しかし、現在、これはブラウザに直接組み込まれ始めているようです。だから今これを行うことができます：

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専用のものですか？
  • なぜGoogle Chromeなのか？他のどこでもサポートされていますか？他のどこかでサポートする計画はありますか？
  • ChromeのJavaScriptランタイムを使用するnode.jsを確認しましたが、そこでは機能しません。何故なの？
  • リストにある機能以外の方法でタイムゾーンデータにアクセスできますか？文字列のフォーマット時にのみ使用できる場合、結果に基づいて計算を行うのは困難な場合があります。

  • これは出力に焦点を当てていますが、入力にどのように使用しますか？コンストラクタでタイムゾーンを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仕様の欠陥により作成された this post で説明されている問題は、正しいデータがTZDBにある場合でも、出力に影響します。古い実装と新しい実装の両方が共存しているのはなぜですか？それはすべて古い方法であるか、すべて新しい方法であると考えるでしょう。たとえば、コンピューターのタイムゾーンが米国東部標準時に設定されている場合：

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

    "11/6/2004 11:00:00 PM"を返します。午前0時に開始し、ローカルタイムゾーンが出力タイムゾーンと一致しているため、午前0時が返されます。しかし、ES5の問題により、提供された入力日付が誤ったUTCポイントに配置されます。

  • IANAがTZDBへのアップデートをリリースするときに、Googleがプッシュすることを期待できますChrome変更を含むアップデート？

javascriptgoogle-chromeinternationalizationtimezoneecmascript-intl
26
Matt Johnson-Pint

更新

APIについてはかなり広範囲にわたる記述があります here

これは新しい規格の一部ですか？おそらくECMAScript 6のどこかに埋葬されているのでしょうか？それとも、Chrome専用のものですか？

はい、これらは ECMAScript国際化API の一部です。 ECMAScriptとは別に実装されていますが、ECMAScript国際化APIを実装するには、まずECMAScript 5.1を正しく実装する必要があります。

なぜGoogle Chromeなのか？他のどこでもサポートされていますか？他のどこかでサポートする計画はありますか？

近年、Google Chromeは、ほとんどが最初に新機能を実装したものです。Mozillaはより保守的です。たとえば、download属性のa属性を実装するかどうかについて議論しています] _要素 IE11 Beta および Opera でも利用可能になりました Firefox 25 で利用可能になります。

ChromeのJavaScriptランタイムを使用するnode.jsを確認しましたが、そこでは機能しません。何故なの？

node.jsは同じエンジン、つまりGoogleからの 別のプロジェクト を使用しますChromeブラウザ。エンジンはEcmascript 5.1を実装しているだけです。これは拡張node.jsです。 Q3のV8 で利用できるようになるので、少し後にnode.jsで使用できます。

これは出力に焦点を当てていますが、入力にどのように使用しますか？コンストラクタのタイムゾーンをDateオブジェクトに渡す方法はありますか？私は以下を試しました：

仕様に日付を入力することについては何もありません。個人的にはこれがどのように役立つかはわかりません。UTCタイムスタンプを送信していないと、DSTから標準時間への移行中に"2013-01-01 12:34:56 America/New_York"のようなものが曖昧になるため、間違っています。

この投稿で説明されている、ECMAScript 5仕様の欠陥によって作成された問題は、正しいデータがTZDBにある場合でも、出力に影響します。

これは入力の問題であり、出力ではありません。繰り返しますが、影響を与えたり検出したりできないローカルタイムゾーンで日付を作成することは間違っています。タイムスタンプコンストラクタオーバーロードまたはDate.UTCを使用します。

IANAがTZDBへのアップデートをリリースするときに、Googleがプッシュすることを期待できますChrome変更を含むアップデート？

仕様には何もありませんが、ルールがあまり遅れていないことを期待するのは妥当だと思います。

21
Esailija

これは新しい規格の一部ですか？おそらくECMAScript 6のどこかに埋葬されているのでしょうか？それとも、Chrome専用のものですか？

実際、それは新しいECMA-402標準の一部です。標準を読むのは非常に困難ですが、 このわかりやすい紹介 があります。

なぜGoogle Chromeなのか？他のどこでもサポートされていますか？他のどこかでサポートする計画はありますか？

MDNにはサポートされているブラウザのリストがあります 。 Bug 853301 によると、Firefox 25で利用可能になる予定です。

ChromeのJavaScriptランタイムを使用するnode.jsを確認しましたが、そこでは機能しません。何故なの？

考えられる理由はたくさんあります。現在のコードベースに達していないか、node.jsが大きく、遅くなります（Mozillaからの以前のバグトラッカーエントリは、タイムゾーンデータがFirefoxのダウンロードサイズを10％増加させ、I/Oを引き起こしたことを示しています）ブラウザの起動中に大幅に増加します。

リストにある機能以外の方法でタイムゾーンデータにアクセスできますか？もしも
文字列をフォーマットするときに使用でき、その結果に基づいて計算を行うのは難しい場合があります。

利用できないようです。さらに、Intl API入門では、UTCとローカルタイムゾーンのみがサポートされることが絶対に必要であると説明しています。

これは出力に焦点を当てていますが、入力にどのように使用しますか？コンストラクタのタイムゾーンをDateオブジェクトに渡す方法はありますか？私は以下を試しました：

Intl APIは、日付/時刻のフォーマット、文字列の照合、および数値のフォーマットについてのみ話します。日時の書式設定は、グレゴリオ暦だけでなく、他の多くの種類の暦（太陰暦、太陰暦など）もサポートしています。

この投稿で説明されている、ECMAScript 5仕様の欠陥によって作成された問題は、正しいデータがTZDBにある場合でも、出力に影響します。古い実装と新しい実装の両方が共存しているのはなぜですか？それはすべて古い方法であるか、すべて新しい方法であると考えるでしょう。たとえば、コンピューターのタイムゾーンが米国東部標準時に設定されている場合：

新しい日付（2004,10,7,0,0）.toLocaleString（ "en-US"、{timeZone： "America/New_York"}）

「11/6/2004 11:00:00 PM」を返します。 >午前0時に開始し、ローカルタイムゾーンが出力タイムゾーンと一致しているため、午前0時を返します。しかし、ES5の問題のために、提供された入力日付が>間違ったUTCポイントに配置されます。

その理由は、ES5は新しい日付への入力が現在のDSTとオフセットを使用して計算されることを義務付けているためです。明らかにこれが指定されているため、変更することはできません。ただし、ChromeはTZDBを使用して、UTCの特定の時点の値からアメリカ/ニューヨークのtzへの変換を行っているため、時刻はESTと見なされます。

IANAがTZDBへのアップデートをリリースするときに、Googleがプッシュすることを期待できますChrome変更を含むアップデート？

私はそう信じます

6
Antti Haapala