6

何が起きてる：

> new Date('Apr 15 2013');
Mon Apr 15 2013 00:00:00 GMT+0100 (GMT Daylight Time)
> new Date('04/15/2013');
Mon Apr 15 2013 00:00:00 GMT+0100 (GMT Daylight Time)
> new Date('2013-04-15');
Mon Apr 15 2013 01:00:00 GMT+0100 (GMT Daylight Time)

明らかに、1 つは UTC 時間として解釈され、他の 2 つは現地時間として解釈されます。解析の違いの原因は何ですか?

4

3 に答える 3

2

仕様から：

Stringは、 String の内容に応じて、現地時間、UTC 時間、または他のタイム ゾーンの時間として解釈される場合があります。この関数は、まず、日時文字列形式 ( 15.9.1.15 ) で呼び出されたルールに従って、文字列の形式を解析しようとします。文字列がその形式に準拠していない場合、関数は実装固有のヒューリスティックまたは実装固有の日付形式にフォールバックする可能性があります。

あなたが提供したすべての形式のうち、'2013-04-15'公式にサポートされているのは のみであるため、他の形式は実装依存の動作にフォールバックするようです。

于 2013-02-20T09:55:48.947 に答える
2

コンストラクターはDateに委任され、 2 つのバリアントDate.parseがあるように見えます。Date.parse

時刻を表す文字列を指定すると、parse は時刻の値を返します。RFC2822 / IETF 日付構文 (RFC2822 セクション 3.3)を受け入れます (例: "Mon, 25 Dec 1995 13:30:00 GMT")。これは、米国本土のタイムゾーンの略語を認識しますが、一般的にはタイムゾーンのオフセットを使用します。たとえば、「1995 年 12 月 25 日月曜日 13:30:00 GMT+0430」(グリニッジから東へ 4 時間 30 分) のようにします。子午線）。タイム ゾーンを指定しない場合は、ローカル タイム ゾーンが想定されます。GMT と UTC は同等と見なされます。

または、日付/時刻文字列は ISO 8601 形式の場合もあります。JavaScript 1.8.5 (Firefox 4) 以降では、ISO 8601 のサブセットがサポートされています。たとえば、「2011-10-10」（日付のみ）または「2011-10-10T14:48:00」（日付と時刻）を渡して解析できます。

明らかに、これらはローカルのタイムゾーンに関して異なる動作をします

編集：これは実装定義のようです

于 2013-02-20T09:55:48.773 に答える
2

3 番目の例は、仕様によって実際に説明されている唯一の例です。Date単一の引数でコンストラクターを呼び出すと、次のようになります(コンストラクターに渡される文字列はどこにありますか)。v

メソッド (15.9.4.2)vとまったく同じ方法で、日付として解析します。この日付の時間値としますparse。V

このparseメソッドは、文字列の解析を試みます (強調を追加)。

String は、 String の内容に応じて、現地時間、UTC 時間、または他のタイム ゾーンの時間として解釈される場合があります。この関数は、まず、日時文字列形式 (15.9.1.15) で呼び出された規則に従って、文字列の形式を解析しようとします。

文字列がその形式に準拠していない場合、関数は実装固有のヒューリスティックまたは実装固有の日付形式にフォールバックする可能性があります。

そして、「日時文字列形式」はYYYY-MM-DDTHH:mm:ss.sssZであり、フォームの短いバージョンも定義しYYYY-MM-DDます。これは、3番目の例で使用するものです。

他の例では、解析は失敗し、動作は実装定義です。

于 2013-02-20T09:56:01.710 に答える