2

ブラウザー側（Safari 5.0.1）で文字列をDate（）コンストラクターに渡す場合、遠い将来の日付の計算には厄介なことがあります。

22034年の2月から3月の移行に絞り込みました。

d = new Date('1 Mar 22034')
Tue Feb 28 22034 00:00:00 GMT+0000 (GMT)

それ以降の日付をフィードすると、コンストラクターは常にDateオブジェクトを1日遅れて返します。

以前の日付はどうですか？2月の最終日はよさそうだ：

d=new Date('28 Feb 22034')
Tue Feb 28 22034 00:00:00 GMT+0000 (GMT)

私の腸の感覚は、うるう年に関連するバグのように見えることを教えてくれます。しかし、ここでのパターンは何ですか、バグの説明は何でしょうか？

編集：

2月29日をお願いしたらどうですか？

d=new Date('29 Feb 22034')
Wed Mar 01 22034 00:00:00 GMT+0000 (GMT)

これは、2月の最後と1日を返します（その標準的な動作）。

4

1 に答える 1

1

これは、指定する日付形式new Date()が非標準であるためです。あなたが何かを得ているという事実は、Safariがあなたに好意を示しているからです。（有効な形式については、仕様のセクション15.9.1.15を参照してください。基本的には簡略化されたISO-8601です。日付/時刻文字列を解析するための標準を持つことは比較的新しい[第5版]です。）

たとえば、標準のコンストラクターを使用する場合new Date (22034, 2, 1)（月はゼロから始まるため、22034年3月1日）、正常に機能します。このようにテストできます（ライブコピー）：

display("With non-standard string: " + new Date("1 Mar 22034"));
display("Using standard constructor: " + new Date(22034, 2, 1));

Safari for Windowsを使用すると、次のようになります。

非標準文字列の場合：Tue Feb 28 22034 00:00:00 GMT + 0000（GMT Standard Time）
標準コンストラクターの使用：Wed Mar 01 22034 00:00:00 GMT + 0000（GMT Standard Time）

ご覧のとおり、最初の行は間違った日付を示し、2番目の行は正しい日付を示しています。

標準のコンストラクターは、Chrome、Opera、Firefox（すべてUbuntu）、IE6、IE7、IE8でも正しく機能します：http：//jsbin.com/ogiqu

Safariがその日付を処理できないことが本当に真実である場合（指定した非標準の文字列を確実に解析しないのとは対照的に）、Safari固有の驚くべきバグになります。仕様のセクション15.9.1.1から：

時間は、1970年1月1日UTCからのミリ秒単位のECMAScriptで測定されます。時間値では、うるう秒は無視されます。1日あたり正確に86,400,000ミリ秒あると想定されています。ECMAScript数値は、–9,007,199,254,740,991から9,007,199,254,740,991までのすべての整数を表すことができます。この範囲は、1970年1月1日UTCから、順方向または逆方向のいずれかで約285、616年以内の任意の瞬間のミリ秒単位の精度で時間を測定するのに十分です。

しかし、Safariはゲレンデ外に出てはいけない場合は問題なく処理できるように見えるので、明らかに問題は非標準文字列のコードの解析にあります。

于 2010-11-30T16:47:54.753 に答える