私はJSONの日付フォーマットについて非常に多くの異なる標準を見ました:
"\"\\/Date(1335205592410)\\/\"" .NET JavaScriptSerializer
"\"\\/Date(1335205592410-0500)\\/\"" .NET DataContractJsonSerializer
"2012-04-23T18:25:43.511Z" JavaScript built-in JSON object
"2012-04-21T18:25:43-05:00" ISO 8601
どちらが正しいですか?それとも最高?これに関する何らかの標準はありますか?
JSON 自体は日付を表現する方法を指定しませんが、JavaScriptは表現します。
あなたはshouldDate
の toJSON
メソッドによって出力されるフォーマットを使用する必要があります:
2012-04-23T18:25:43.511Z
その理由は次のとおりです。
それは人間が読めるだけでなく簡潔です
正しく並べ替えます
秒の小数部分が含まれており、年表を再確立するのに役立ちます
ISO 8601 に準拠
ISO 8601は10年以上にわたり国際的に確立されています
と言われている、これまでに書かれたすべての日付ライブラリは「1970年からのミリ秒」を理解できます。簡単に移植できるように、 ThiefMaster が正しいです。
JSONは日付について何も知りません。 .NETがすることは非標準的なハック/エクステンションです。
私はJavaScriptでDate
オブジェクトに簡単に変換できるフォーマット、すなわち new Date(...)
に渡すことができるフォーマットを使います。最も簡単でおそらく最も移植性の高い形式は、1970年以降のミリ秒を含むタイムスタンプです。
正しいフォーマットはありません ;JSON仕様は日付を交換するためのフォーマットを指定していません。
最良の形式は、おそらく ISO 8601形式( Wikipediaを参照 )で表される日付です。これはよく知られ広く使用されているフォーマットであり、さまざまな言語で扱うことができるため、相互運用性に非常に適しています。たとえば、生成されたJSONを管理している場合は、データをJSON形式で他のシステムに提供するため、日付交換形式として8601を選択することをお勧めします。
たとえば、生成されたjsonを制御できない場合、既存のいくつかの異なるシステムからjsonを利用している場合、これを処理する最善の方法は、想定されるさまざまなフォーマットを処理する日付解析ユーティリティ関数を用意することです。
RFC 7493(I-JSONメッセージフォーマット) }から:
I-JSONは、あなたが求める相手に応じて、インターネットJSONまたはInteroperable JSONのどちらかを表します。
プロトコルはしばしばタイムスタンプまたは期間を含むように設計されたデータ項目を含みます。 RFC 3339 ので指定されているように、すべてのそのようなデータ項目はISO 8601フォーマットの文字列値として表現されることを推奨します。 。[]小文字ではなく、タイムゾーンがデフォルトで含まれておらず、オプションの末尾の秒が[00]であっても含まれていることを示します。期間を含むすべてのデータ項目がRFC 3339の[A]付録Aの「期間」の生成に準拠していることも推奨されます。同じ追加の制限事項があります。
参考までに、私はこのフォーマットが使われているのを見ました:
Date.UTC(2017,2,22)
$.getJSON()
関数でサポートされている _ jsonp _ で動作します。私はこのアプローチを推奨するために私たちが行っているかどうかわからない...人々がこのようにそれをやっているので可能性としてそこにそれを捨てなさい。
FWIW: /通信プロトコルではEpochからの秒数もEpochからのミリ秒数も使用しないでください。これは、うるう秒のランダム化された実装のおかげで危険をはらんでいるからです。 ).
ペット嫌いのようなものですが、多くの人がUTCはGMTの新しい名前だと信じています - 間違っています。あなたのシステムがうるう秒を実装していないなら、あなたはGMTを使用しています(間違っているにもかかわらず、しばしばUTCと呼ばれます)。うるう秒を完全に実装していれば、本当にUTCを使用していることになります。将来のうるう秒は知ることができません。それらは必要に応じてIERSによって公開され、絶えず更新を必要とします。うるう秒を実装しようとしているが古くなった参照テーブルを含むシステムを実行している(あなたが思うより一般的な)場合、あなたはGMTもUTCも持っていない、あなたはUTCのふりをする素晴らしいシステムを持っています。
これらの日付カウンタは、細かいフォーマット(y、m、dなど)で表現された場合にのみ互換性があります。それらはEpochフォーマットでは決して互換性がありません。心に留めておきます。
niversal interoperabilityの最適な形式はISO-8601文字列ではなく、EJSONが使用する形式だと思います。
{ "myDateField": { "$date" : <ms-since-Epoch> } }
ここで説明されているとおり: https://docs.meteor.com/api/ejson.html
利点
結論
私は、人間が読める形式(ISO-8601文字列)が有用であり、80%のユースケースでconvenientであることを理解しています。実際、誰にも言わないでくださいnotアプリケーションが理解している場合、日付をISO-8601文字列として保存する、but、特定の値を保証する必要がある普遍的に受け入れられたトランスポート形式確かに日付であるが、あいまいさをどのように許容し、それほど多くの検証が必要なのでしょうか?
JSON自体には日付形式はありません。誰かが日付を保管する方法には関係ありません。しかし、この質問はjavascriptでタグ付けされているので、私はあなたがJSONにjavascriptの日付を保存する方法を知りたいと思うと思います。 JSON.stringify
メソッドに日付を渡すだけで、デフォルトでDate.prototype.toJSON
が使用されます。これは、Date.prototype.toISOString
( Date.toJSON )を使用します。
const json = JSON.stringify(new Date());
const parsed = JSON.parse(json); //2015-10-26T07:46:36.611Z
const date = new Date(parsed); // Back to date object
また、JSON文字列を読み取るたびにISO文字列を自動的にJavaScriptの日付に変換するために、JSON.parse
( MDN on JSON.parse )のreviver
パラメータを使用すると便利です。
const someObj = {
a: 'foo',
b: new Date()
}
const json = JSON.stringify(someObj);
const parsed = JSON.parse(json, (key, value) => {
const isoDate = new RegExp(/\d{4}-[01]\d-[0-3]\dT[0-2]\d:[0-5]\d:[0-5]\d\.\d+([+-][0-2]\d:[0-5]\d|Z)/);
if (typeof value === 'string' && value.match(isoDate)){
return new Date(value); // isostring, so cast to js date
}
return value;
});
console.log(parsed.b); // Date object
疑わしい場合は、F12(FirefoxではCtrl + K)を押して最新のブラウザーのjavascript Webコンソールに移動し、次のように記述します。
new Date().toISOString()
出力されます:
「2019-07-04T13:33:03.969Z」
多田!!
好ましい方法は2018-04-23T18:25:43.511Z
...を使うことです。
下の図は、これがなぜ好ましい方法であるかを示しています。
ご覧のとおり、DateにはネイティブのメソッドtoJSON
があります。これはこの形式でreturn
であり、Date
に簡単に変換できます。
Sharepoint 2013では、JSONでデータを取得することは、日付をISO形式にする必要があるため、日付を日付のみの形式に変換する形式はありません
yourDate.substring(0,10)
これはあなたにとって役に立つかもしれません