これはバグだと思います。
現在の動作は何ですか?
現在、ログアウトする素敵な日付オブジェクトがあります
2016年4月29日金曜日13:33:00GMT + 0100(BST)
このオブジェクトが$ httpを介してPOSTされると、ネットワーク要求で次のことが観察されます。
2016-04-28T12:33:00.000Z
したがって、$ httpオブジェクトは1時間を差し引き、英国夏時間のBSTを時間から効果的に削除します。 したがって、これはこのオフセットなしでデータベースに保存されます。 この日付をすぐに読むと戻ってきますが、システムはどのようにして時間を追加する必要があるかを知ることができますか?
したがって、ユーザーが別のタイムゾーンにいることも想像してみてください。たとえば、5時間先にすると、システムは5時間を差し引きます...時間は、作成されたコンテキストに依存します。 つまり、タイムゾーン情報を削除しないでください。
これはChromeで見られます。 Angular 1.4.2
これはAngular固有のものではありません。 これは標準のJSON.stringify
動作です。
基本的に、データを投稿するとき、 $http
データをJSONに変換します( JSON.stringify()
経由)。 JavaScriptでは、DateオブジェクトのJSON表現はそのISO-8601形式です(これは[ネットワーク]タブに表示されます)。
とにかく、Dateオブジェクトにはタイムゾーン情報がないため、情報が削除されることはありません。 現在のロケール(Dateオブジェクトで表される日付とは完全に独立しています)にはタイムゾーンオフセットがあり、ブラウザはconsole.log
使用すると、そのオフセットに従って日付をフォーマットします。
これはAngularの問題ではないため、終了します。
@gkalpakまず、Dateオブジェクトにタイムゾーン情報がないと言うのは正しくないと思います。 new Date()で日付を作成すると、タイムゾーン情報はデフォルトでローカルゾーンになります。 DateオブジェクトにはgetTimezoneOffset
toISOString
メソッドと
new Date().getTimezoneOffset()
-330
new Date().toISOString()
"2018-12-04T05:40:37.399Z"
次に、 JSON.stringify()
もゾーン値を削除しません。以下は、ブラウザーコンソールで見たものです。これは同じで、ブラウザーは私たちにとって良いものを何も印刷していません。
JSON.stringify({d:new Date()})
"{"d":"2018-12-04T05:42:08.973Z"}"
したがって、APIがそれらのミリ秒値を持たないISO日付をレンダリングし、UIが日付を選択して日付を変更するだけのdatepickerを使用している場合、日付をISO形式に変換して送り返すときにAngularはミリ秒を持たないだろうと私はまだ信じています価値。
まず、Dateオブジェクトにタイムゾーン情報がないと言うのは正しくないと思います。
:grin: Date
オブジェクト_ "は、1970年1月1日UTCからのミリ秒数である時間値に基づいて1つの瞬間を表します"と言うのは正しいと思います。 _(出典: MDN )。 したがって、基本的に各Date
インスタンスは、この1つの値についてのみ認識し、その情報とロケール/システム状態(タイムゾーンオフセットなど)に基づいて、他のすべての表現が誘導されます。
Dateオブジェクトには
getTimezoneOffset
toISOString
メソッドと
これらはDate
プロトタイプ(ソース: MDN )のメソッドであり、 Date
オブジェクト(別名インスタンス)自体のメソッドではありません。
具体的には、 getTimezoneOffset()の値は、現在のロケール(ホストシステムの設定)によって異なります。 これが、同等のsetTimezoneOffset()
メソッドがない理由であり、同じシステム上のすべてのDate
オブジェクトがgetTimezoneOffset()
に対して同じ値を返す理由です。例:
const d1 = new Date('December 15, 2018 12:34:56'); // No timezone; uses the current system locale.
const d2 = new Date('December 15, 2018 12:34:56 GMT+10'); // Uses GTM+10 as timezone.
d1.getTimezoneOffset() === d2.getTimezoneOffset(); // true
したがって、 Date
渡される日付文字列表現で指定されたタイムゾーン情報は、その文字列を解析し、上記のように特定の時点にマップするためにのみ使用されます。 結果のDate
オブジェクトは、タイムゾーンについて何も知りません:smiley:
toISOString()メソッドは、提案したようにタイムゾーン情報を出力しません。 最後にZ
を追加するだけです。これは、 UTC
ます。
次に、
JSON.stringify()
もゾーン値を削除しません
上で説明したように、UTCで日付値を表すtoISOString()
を使用します(したがって、それを示すために最後にZ
を追加します)。 返される文字列にタイムゾーン情報はありません。
したがって、APIがそれらのミリ秒値を持たないISO日付をレンダリングし、UIが日付を選択して日付を変更するだけのdatepickerを使用している場合、日付をISO形式に変換して送り返すときにAngularはミリ秒を持たないだろうと私はまだ信じています価値。
ミリ秒がそれと何の関係があるのか私にはわかりません。 タイムゾーン情報について話していました。
繰り返しますが、これはAngularJSとは何の関係もありません。 これは、組み込みオブジェクト( Date
やJSON
)が相互に作用する方法です。
最も参考になるコメント
:grin:
Date
オブジェクト_ "は、1970年1月1日UTCからのミリ秒数である時間値に基づいて1つの瞬間を表します"と言うのは正しいと思います。 _(出典: MDN )。 したがって、基本的に各Date
インスタンスは、この1つの値についてのみ認識し、その情報とロケール/システム状態(タイムゾーンオフセットなど)に基づいて、他のすべての表現が誘導されます。#
これらは
Date
プロトタイプ(ソース: MDN )のメソッドであり、Date
オブジェクト(別名インスタンス)自体のメソッドではありません。具体的には、 getTimezoneOffset()の値は、現在のロケール(ホストシステムの設定)によって異なります。 これが、同等の
setTimezoneOffset()
メソッドがない理由であり、同じシステム上のすべてのDate
オブジェクトがgetTimezoneOffset()
に対して同じ値を返す理由です。例:したがって、
Date
渡される日付文字列表現で指定されたタイムゾーン情報は、その文字列を解析し、上記のように特定の時点にマップするためにのみ使用されます。 結果のDate
オブジェクトは、タイムゾーンについて何も知りません:smiley:toISOString()メソッドは、提案したようにタイムゾーン情報を出力しません。 最後に
Z
を追加するだけです。これは、UTC
ます。#
上で説明したように、UTCで日付値を表す
toISOString()
を使用します(したがって、それを示すために最後にZ
を追加します)。 返される文字列にタイムゾーン情報はありません。#
ミリ秒がそれと何の関係があるのか私にはわかりません。 タイムゾーン情報について話していました。
繰り返しますが、これはAngularJSとは何の関係もありません。 これは、組み込みオブジェクト(
Date
やJSON
)が相互に作用する方法です。