javascript - 「正しい」JSON日付形式は何ですか?

Question

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

どれが正しいですか？それとも最高？これには何らかの基準がありますか？

score 2215 · Accepted Answer

JSON自体は日付の表現方法を指定しませんが、JavaScript は指定します。

のメソッドによって出力される形式を使用する必要があります。DatetoJSON

2012-04-23T18:25:43.511Z

理由は次のとおりです。

人間が読める形式ですが、簡潔でもあります
正しくソートされます
小数秒が含まれているため、年表を再確立するのに役立ちます
ISO8601に準拠しています
ISO 8601 は 10 年以上にわたって国際的に確立されています。
ISO 8601 はW3C、RFC3339、およびXKCDによって承認されています。

そうは言っても、これまでに作成されたすべての日付ライブラリは、「1970 年からのミリ秒」を理解できます。したがって、簡単に移植できるという点では、ThiefMasterが適切です。

score 144 · Accepted Answer

JSONは日付について何も知りません。.NETが行うことは、非標準のハック/拡張です。

JavaScriptでオブジェクトに簡単に変換できる形式Date、つまりに渡すことができる形式を使用しますnew Date(...)。最も簡単でおそらく最も移植性の高い形式は、1970年以降のミリ秒を含むタイムスタンプです。

score 55 · Accepted Answer

正しい形式はありません; JSON仕様では、日付を交換するための形式が指定されていないため、さまざまな方法があります。

最適な形式は、間違いなくISO 8601形式で表された日付です（ウィキペディアを参照）。これはよく知られており、広く使用されている形式であり、さまざまな言語で処理できるため、相互運用性に非常に適しています。たとえば、生成されたjsonを制御できる場合は、json形式で他のシステムにデータを提供します。日付交換形式として8601を選択することをお勧めします。

生成されたjsonを制御できない場合、たとえば、いくつかの異なる既存のシステムからjsonを使用している場合、これを処理する最良の方法は、予想されるさまざまな形式を処理する日付解析ユーティリティ関数を使用することです。

score 21 · Accepted Answer

参考までに、この形式が使用されているのを見てきました。

Date.UTC(2017,2,22)

関数でサポートされているJSONPで動作し$.getJSON()ます。このアプローチを推奨するところまで行くかどうかはわかりません...人々がこのようにやっているので、可能性としてそれを投げ出すだけです。

FWIW:通信プロトコルでエポックからの秒数やエポックからのミリ秒数を使用しないでください。これは、閏秒のランダム化された実装のおかげで危険を伴うためです (送信者と受信者の両方が UTC 閏秒を適切に実装しているかどうかはわかりません)。

一種のペット嫌いですが、UTC は GMT の新しい名前にすぎないと多くの人が信じています。システムがうるう秒を実装していない場合は、GMT (正しくないにもかかわらず UTC と呼ばれることが多い) を使用しています。うるう秒を完全に実装すると、実際に UTC を使用していることになります。将来のうるう秒を知ることはできません。必要に応じて IERS によって公開され、定期的な更新が必要です。うるう秒を実装しようとしているが、古い参照テーブルを含むシステムを実行している場合 (思っているよりも一般的です)、GMT も UTC もありません。UTC のふりをしている不安定なシステムです。

これらの日付カウンターは、分解された形式 (y、m、d など) で表現されている場合にのみ互換性があります。エポック形式では決して互換性がありません。心に留めておきます。

score -3 · Accepted Answer

それは解析サーバーで私にとってはうまくいきます

{
    "ContractID": "203-17-DC0101-00003-10011",
    "Supplier":"Sample Co., Ltd",
    "Value":12345.80,
    "Curency":"USD",
    "StartDate": {
                "__type": "Date",
                "iso": "2017-08-22T06:11:00.000Z"
            }
}

score -7 · Accepted Answer

これに対する正しい答えは 1 つしかなく、ほとんどのシステムは間違っています。エポックからのミリ秒数、別名 64 ビット整数。タイムゾーンは UI の問題であり、アプリレイヤーまたはデータベースレイヤーには関係ありません。64ビット整数として保存することがわかっているのに、データベースがタイムゾーンを気にするのはなぜですか。その後、変換計算を行います。

余分なビットを取り除き、日付を UI までの数値として扱います。単純な算術演算子を使用して、クエリとロジックを実行できます。

score -18 · Accepted Answer

それは本当にユースケースに依存すると思います。多くの場合、次のように、(日付を文字列にレンダリングする代わりに) 適切なオブジェクトモデルを使用する方が有益な場合があります。

{
"person" :
      {
 "name" : {
   "first": "Tom",
   "middle": "M",
  ...
}
 "dob" :  {
         "year": 2012,
         "month": 4,
         "day": 23,
         "hour": 18,
         "minute": 25,
         "second": 43,
         "timeZone": "America/New_York"
    }   
   }
}

確かに、これは RFC 3339 よりも冗長ですが、次のようになります。

それは人間が読めるものでもあります
適切なオブジェクトモデルを実装している (JSON で許可されている限り、OOP の場合と同様)
タイムゾーンをサポートします（指定された日時の UTC オフセットだけではありません）
ミリ秒、ナノ秒、または単に小数秒などの小さな単位をサポートできます
個別の解析ステップ (日時文字列を解析するため) は必要ありません。JSON パーサーがすべてを行います。
任意の日時フレームワークまたは任意の言語での実装による簡単な作成
他の暦スケール (ヘブライ語、中国語、イスラム教など) や時代 (AD、BC など) をサポートするように簡単に拡張できます。
10000 年は安全です ;-) (RFC 3339 はそうではありません)
終日日付と浮動時間をサポートします (Javascript はサポートしDate.toJSON()ません)

正しい並べ替え (RFC 3339 の funroll で指摘されているように) は、日付を JSON にシリアル化するときに本当に必要な機能ではないと思います。また、同じタイムゾーンオフセットを持つ日時にのみ当てはまります。

javascript - 「正しい」JSON日付形式は何ですか?

15 に答える 15

Related

Reference