春に向けて: Web での過去の日付や時刻の計算を進歩させる

春に向けて: Web での過去の日付や時刻の計算を進歩させる

Web 開発者は、世界中のユーザーに向けたグローバル対応アプリケーションを作成したいと常に思っています。Internet Explorer 10 は、基底の OS では既に可能になっている過去の夏時間を Web 開発者が適切に処理できるようにします。これにより、アプリやサイトではさまざまなタイム ゾーン間でより正確に過去の日付と時刻をやり取りできるようになります。

今年初めに、私たちは新たな ECMAScript 実装 API を調査しました。この API は、Web 標準プラットフォーム内からの通貨表示やロケール依存文字列の比較や、以前はネイティブの相互運用性またはプラグインの使用が必要だったシナリオなどを可能にします。Web プラットフォームをグローバル対応にするのと同じテーマに沿って、ブラウザーが過去の日付と時刻のゾーン情報をやり取りする方法を体験するデモ (英語) を発表しました。

過去の日付と時刻の計算への挑戦

過去の株価や誕生日、過去の出来事など、過去の日付を扱う際、Web 開発者は多くの場合、サーバー上で検証をしなければなりません。現在、JavaScript エンジンによって日付に対して行われる夏時間調整は、.NET、PHP / Perl、および Java など、サーバーで一般的に実行されるプラットフォームほど正確ではないため、開発者は夏時間調整をサーバーに頼る必要があります。JavaScript での過去の日付が正確でないことに加え、ブラウザー プラットフォーム間で日付を相互運用できないことがよくあります。このため、開発者は、JavaScript で生成された夏時間調整日付を信頼して使用することができません。

IE10 は、ECMAScript 6 (英語) の草案仕様の 15.9.1.8 項に対する修正に対応した、より正確な夏時間調整日付を備えた最初のブラウザーです。Web プラットフォームの機能を、Web 開発者が目的を達成するためにサーバーとのやり取りが必要な複数のシナリオに基づいて拡張しました。私たちは、JavaScript エンジンが過去の日付を解釈し、夏時間用に調整する方法に注目しました。そして、既存の JavaScript の実装での夏時間の正確な調整を妨げている欠陥を ECMAScript 標準仕様で発見しました。私たちは、ECMAScript 標準委員会と共に、次のバージョンの ECMAScript 仕様をより正確なものにする修正を提案 (英語) しました。

Test Drive デモの体験

この問題の説明と、お気に入りのブラウザーが過去の日付をどのように処理しているのかを確認するには、Historic Dates Test Drive デモ (英語) を、デモの下にある宇宙航空の歴史を示すイベントのアイコンをクリックしてご覧ください。デモを見ているとき、ブラウザーは、イベントが発生した過去の日付を読み取り、イベント発生時についてブラウザーで既定の設定となっている夏時間ルールを適用して日付と時刻を示します。デモでは、この過去の日付と夏時間が適切かどうかを検証します。

上記のケースでは、宇宙探査機 IMAGE が発射されたときの過去の日付を表示する際に、太平洋標準時ゾーンの Windows 8 コンピューター上で実行している IE10 は、正確に過去の出来事の適切な日付と夏時間を決定できています。

注: 夏時間はすべてのタイム ゾーンに適用できません。夏時間ルールが変更されたことのないタイム ゾーンも存在します。ご使用のシステムがそのようなタイム ゾーンである場合は、夏時間ルールがあり一定の期間が経つと適用されるタイム ゾーン (太平洋標準時など) に変更して、デモを再度実行することをお勧めします。IE10 では、システムのタイム ゾーンの変更が即座に反映されます。他のブラウザーを使用している場合は、タイム ゾーンの変更を有効にするにため、ブラウザーの再起動が必要な場合があります。

IE10 での過去の日付と時刻の処理の向上

現在の ECMAScript 仕様が JavaScript での夏時間の日付調整の正確さにどのような影響を与えているかに注目してみましょう。

ECMAScript 5.1 (英語) の 15.9.1.8 項では、Internet Explorer の Chakra (英語) エンジンのような JavaScript 実装で過去の日付を処理する際に準拠する以下の仕様を規定しています。

ECMAScript の実装では、夏時間が反映された正確な時刻かどうかを判断するのではなく、現在の夏時間アルゴリズムが当時使われていたとして夏時間が有効であるかどうかを判断すべきです。これにより、一年中夏時間を採用するロケールの年を考慮するといった複雑さを回避できます。

ホスト環境が夏時間を判断する機能を提供する場合、ECMAScript の実装では、ホスト環境が夏時間情報を提供する同等の年 (うるう年で同じ曜日で始まる) に、対象の年を自由にマッピングできます。唯一の制限は、すべての同等の年が同じ結果を出さなければならない、ということです。

簡単に言うと、過去の日付を処理する場合、JavaScript の実装では、現在の夏時間アルゴリズムを過去の日付に適用するか、またはその年の 1 月 1 日の曜日を判断し、うるう年かどうかを計算し、同じ属性 (開始曜日とうるう年) を持つ年の現在の夏時間ルールを検索し、その夏時間を過去の日付に適用します。後者の例としては、1972 年が土曜日に始まるうるう年です。土曜日に始まる次のうるう年は 2000 年です。仕様を言葉だけで解釈すると、JavaScript の実装では、現在の夏時間アルゴリズムを使用するか、1972 年の日付を操作している際に 2000 年の夏時間ルールを使用する可能性があります。

夏時間ルールを過去の日付に適用する際、上記のルールのどちらかを使用すると 2 つの大きな問題が発生します。1 つ目の問題は、特定のタイム ゾーンの夏時間ルールが一定ではなく、時間の経過によって変化するということです。このため、間違ったルールが過去の日付に適用される可能性があります。2 つ目は、一定の期間に夏時間ルールが変化するタイム ゾーンの場合、Web アプリケーションは、実行される OS プラットフォームによって計算された過去の日付のパリティを保持できなくなり、Web アプリケーションと実行中のプラットフォームとの間の相互運用性の問題などを開発者に解決 (英語) させる結果となります。

前述した 15.9.1.8 項の ECMAScript 5.1 仕様により、実装での夏時間の調整は不正確で、正確さが制約されます。これは直観に反するもので、実際にはブラウザー間でのコンセンサスが形成されていません。15.9.1.8 項にあるようにタイム ゾーンのオフセット動作を制約するのではなく、DaylightSavingsTA 実装に依存したままの仕様にすべきです。

私たちのテストが示すのは、既存のブラウザー実装 (最新バージョン) のどれもが、プラットフォーム間で標準として指定された動作に完全に準拠しておらず、日付を扱う際の夏時間調整が正確でないことです。以下の例は、米国の太平洋標準時ゾーンでの差異を示しています。

この日付では Chrome、FireFox、Node が OS 間で一貫していません。ほとんどどれもが間違っていて、実際の夏時間調整は 480 です。

この日付では、2、3 の環境が再度 ES5.1 ルールに違反しています (これらの 2 年はどちらも火曜日に始まり、うるう年ではありません) が、単一の OS (Windows と Mac のどちらも) 上であっても相違があります。

今後を見据えて

Internet Explorer 10 から、Chakra エンジンでは、ローカル時間と UTC の変換のために、ブラウザーが実行される Windows プラットフォームから利用できる夏時間情報を使用しています。 

私たちがこの仕様 (英語) の問題を報告した後、ECMAScript 標準委員会と共に、次のバージョンの ECMAScript 仕様をより正確なものにする提案をしました。Web プラットフォームを相互運用が可能でより正確なものにするため、ECMAScript 6 (英語) 仕様の最新の草案では、強化した正確な夏時間ルールのサポートを日付に適用し、より正確な情報を提供する方法について詳細に規定しています。IE10 は、この更新された仕様に準拠する最初のブラウザーです。Web 開発者がリッチなグローバル対応のアプリケーションを作成できるように、他のブラウザーも次のリリースでこの問題に対処するためのサポートを拡大するよう希望します。

Web プラットフォームの重要性は引き続き大きくなっていくので、カレンダー アプリケーション、スプレッドシート、プロジェクト管理ソフトウェアなどで使用されるなど、リッチ アプリケーションのロジック全体が JavaScript で書かれることが多くなっています。開発者が互換性を保持できるように、IE10 の標準モードでのみこの変更が有効です。Web アプリケーションで過去の日付を計算する際、カスタム ロジックでブラウザーの不正確さを回避している場合は、Web アプリケーションを IE10 で動作するようにアップグレードしてもカスタム ロジックがそのまま適切に動作させることができます。

-- Suresh Jayabalan、プログラム マネージャー、JavaScript チーム