Format tanggal JSON "benar"

Saya telah melihat begitu banyak standar berbeda untuk format tanggal 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

Yang mana yang benar? Atau yang terbaik? Apakah ada standar dalam hal ini?

JSON sendiri tidak menentukan bagaimana tanggal harus diwakili, tetapi JavaScript melakukannya.

Anda harus menggunakan format yang dipancarkan oleh Date's toJSONmetode:

2012-04-23T18:25:43.511Z

Inilah alasannya:

1. Itu bisa dibaca manusia tetapi juga ringkas

2. Jenisnya benar

3. Ini termasuk detik fraksional, yang dapat membantu membangun kembali kronologi

4. Sesuai dengan ISO 8601

5. ISO 8601 telah mapan secara internasional selama lebih dari satu dekade

6. ISO 8601 didukung oleh W3C , RFC3339 , dan XKCD

Yang sedang berkata , setiap perpustakaan tanggal yang pernah ditulis dapat memahami "milidetik sejak tahun 1970". Jadi untuk portabilitas yang mudah, ThiefMaster benar.

JSON tidak tahu apa-apa tentang kencan. Apa yang dilakukan .NET adalah peretasan / ekstensi non-standar.

Saya akan menggunakan format yang dapat dengan mudah dikonversi ke Dateobjek dalam JavaScript, yaitu yang dapat diteruskan ke new Date(...). Format termudah dan mungkin paling portabel adalah cap waktu yang mengandung milidetik sejak tahun 1970.

Tidak ada format yang tepat ; The JSON Spesifikasi tidak menentukan format untuk bertukar tanggal yang mengapa ada begitu banyak cara yang berbeda untuk melakukannya.

Format terbaik adalah tanggal yang direpresentasikan dalam format ISO 8601 ( lihat Wikipedia ); itu adalah format yang terkenal dan banyak digunakan dan dapat ditangani di berbagai bahasa, membuatnya sangat cocok untuk interoperabilitas. Jika Anda memiliki kontrol atas json yang dihasilkan, misalnya, Anda memberikan data ke sistem lain dalam format json, memilih 8601 karena format pertukaran tanggal adalah pilihan yang baik.

Jika Anda tidak memiliki kendali atas json yang dihasilkan, misalnya, Anda adalah konsumen json dari beberapa sistem yang ada, cara terbaik untuk menangani ini adalah memiliki fungsi utilitas penguraian tanggal untuk menangani berbagai format yang diharapkan.

Dari RFC 7493 (Format Pesan I-JSON) :

I-JSON adalah singkatan dari Internet JSON atau Interonable JSON, tergantung pada siapa yang Anda tanya.

Protokol sering berisi item data yang dirancang untuk mengandung cap waktu atau jangka waktu. DIREKOMENDASIKAN bahwa semua item data tersebut dinyatakan sebagai nilai string dalam format ISO 8601, sebagaimana ditentukan dalam RFC 3339 , dengan batasan tambahan yang digunakan huruf besar daripada huruf kecil, zona waktu yang dimasukkan tidak default, dan opsional membuntuti detik dimasukkan bahkan ketika nilainya "00". DIREKOMENDASIKAN juga bahwa semua item data yang berisi durasi waktu sesuai dengan produksi "durasi" dalam Lampiran A RFC 3339, dengan batasan tambahan yang sama.

Hanya untuk referensi, saya telah melihat format ini digunakan:

Date.UTC(2017,2,22)

Ia bekerja dengan JSONP yang didukung oleh $.getJSON()fungsi. Tidak yakin saya akan merekomendasikan pendekatan ini ... hanya membuangnya di luar sana sebagai kemungkinan karena orang melakukannya dengan cara ini.

FWIW: Jangan pernah menggunakan detik sejak zaman dalam protokol komunikasi, atau milidetik sejak zaman, karena ini penuh dengan bahaya berkat implementasi acak dari detik kabisat (Anda tidak tahu apakah pengirim dan penerima sama-sama menerapkan detik kabisat UTC dengan benar).

Agak benci binatang peliharaan, tetapi banyak orang percaya bahwa UTC hanya nama baru untuk GMT - salah! Jika sistem Anda tidak menerapkan detik kabisat maka Anda menggunakan GMT (sering disebut UTC meskipun salah). Jika Anda menerapkan sepenuhnya detik kabisat Anda benar-benar menggunakan UTC. Detik lompatan di masa depan tidak dapat diketahui; mereka dipublikasikan oleh IERS seperlunya dan membutuhkan pembaruan yang konstan. Jika Anda menjalankan sistem yang mencoba menerapkan detik kabisat tetapi berisi dan tabel referensi kedaluwarsa (lebih umum daripada yang Anda kira), maka Anda tidak memiliki GMT, atau UTC, Anda memiliki sistem miring yang berpura-pura menjadi UTC.

Penghitung tanggal ini hanya kompatibel ketika dinyatakan dalam format rusak (y, m, d, dll). Mereka TIDAK PERNAH kompatibel dalam format zaman. Ingatlah itu.

Jika ragu cukup buka konsol web javascript browser modern dengan menekan F12 (Ctrl + K di Firefox) dan tulis yang berikut ini:

new Date().toISOString()

Akan menghasilkan:

"2019-07-04T13: 33: 03.969Z"

Ta-da !!

Saya percaya bahwa format terbaik untuk interoperabilitas universal bukanlah string ISO-8601, melainkan format yang digunakan oleh EJSON:

{ "myDateField": { "$date" : <ms-since-epoch> } }

Seperti dijelaskan di sini: https://docs.meteor.com/api/ejson.html

Manfaat

1. Kinerja parsing: Jika Anda menyimpan tanggal sebagai string ISO-8601, ini bagus jika Anda mengharapkan nilai tanggal di bawah bidang tertentu, tetapi jika Anda memiliki sistem yang harus menentukan tipe nilai tanpa konteks, Anda mengurai setiap string untuk sebuah format tanggal.
2. Tidak Perlu untuk Validasi Tanggal: Anda tidak perlu khawatir tentang validasi dan verifikasi tanggal. Bahkan jika sebuah string cocok dengan format ISO-8601, itu mungkin bukan tanggal sebenarnya; ini tidak akan pernah terjadi dengan tanggal EJSON.
3. Deklarasi Jenis yang Tidak Mendua: sejauh sistem data generik berjalan, jika Anda ingin menyimpan string ISO sebagai string dalam satu kasus, dan tanggal sistem nyata dalam kasus lain, sistem generik yang mengadopsi format string ISO-8601 tidak akan mengizinkan hal ini, secara mekanis (tanpa trik melarikan diri atau solusi mengerikan serupa).

Kesimpulan

Saya mengerti bahwa format yang dapat dibaca manusia (string ISO-8601) sangat membantu dan lebih nyaman untuk 80% kasus penggunaan, dan memang tidak seorang pun boleh diberi tahu untuk tidak menyimpan tanggal mereka sebagai string ISO-8601 jika itu adalah aplikasi mereka mengerti, tetapi untuk format transportasi yang diterima secara universal yang harus menjamin nilai-nilai tertentu untuk pasti tanggal, bagaimana kita dapat memungkinkan ambiguitas dan kebutuhan untuk begitu banyak validasi?

JSON sendiri tidak memiliki format tanggal, tidak peduli bagaimana orang menyimpan tanggal. Namun, karena pertanyaan ini ditandai dengan javascript, saya berasumsi Anda ingin tahu cara menyimpan tanggal javascript di JSON. Anda cukup mengirimkan tanggal ke JSON.stringifymetode, dan itu akan digunakan Date.prototype.toJSONsecara default, yang pada gilirannya menggunakan Date.prototype.toISOString( MDN pada 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

Saya juga merasa berguna untuk menggunakan reviverparameter JSON.parse( MDN di JSON.parse ) untuk secara otomatis mengkonversi kembali string ISO ke tanggal javascript setiap kali saya membaca string JSON.

const isoDatePattern = 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)/);

const obj = {
 a: 'foo',
 b: new Date(1500000000000) // Fri Jul 14 2017, etc...
}
const json = JSON.stringify(obj);

// Convert back, use reviver function:
const parsed = JSON.parse(json, (key, value) => {
    if (typeof value === 'string' &&  value.match(isoDatePattern)){
        return new Date(value); // isostring, so cast to js date
    }
    return value; // leave any other value as-is
});
console.log(parsed.b); // // Fri Jul 14 2017, etc...

Cara yang disukai menggunakan 2018-04-23T18:25:43.511Z...

Gambar di bawah ini menunjukkan mengapa ini cara yang disukai:

Jadi seperti yang Anda lihat Date memiliki Metode asli toJSON, yang returndalam format ini dan dapat dengan mudah dikonversi Datelagi ...

Di Sharepoint 2013, mendapatkan data dalam JSON tidak ada format untuk mengonversi tanggal menjadi format hanya tanggal, karena pada tanggal tersebut harus dalam format ISO

yourDate.substring(0,10)

Ini mungkin bermanfaat bagi Anda

"2014-01-01T23: 28: 56.782Z"

Tanggal diwakili dalam format standar dan diurutkan yang mewakili waktu UTC (ditunjukkan oleh Z). ISO 8601 juga mendukung zona waktu dengan mengganti nilai Z dengan + atau - untuk offset zona waktu:

"2014-02-01T09: 28: 56.321-10: 00"

Ada variasi lain dari pengkodean zona waktu dalam spesifikasi ISO 8601, tetapi format –10: 00 adalah satu-satunya format TZ yang didukung parser JSON saat ini. Secara umum lebih baik menggunakan format berbasis UTC (Z) kecuali jika Anda memiliki kebutuhan khusus untuk mengetahui zona waktu di mana tanggal tersebut diproduksi (hanya mungkin dalam pembuatan sisi server).

NB: var date = Date baru (); console.log (tanggal); // Rabu 01 Jan 2014 13:28:56 GMT- 1000 (Waktu Standar Hawaii)

var json = JSON.stringify(date);
console.log(json);  // "2014-01-01T23:28:56.782Z"

untuk memberi tahu Anda bahwa itu cara yang disukai meskipun JavaScript tidak memiliki format standar untuk itu

// JSON encoded date
var json = "\"2014-01-01T23:28:56.782Z\"";

var dateStr = JSON.parse(json);  
console.log(dateStr); // 2014-01-01T23:28:56.782Z

Jika Anda menggunakan Kotlin maka ini akan menyelesaikan masalah Anda. (Format MS Json)

val dataString = "/Date(1586583441106)/"
val date = Date(Long.parseLong(dataString.substring(6, dataString.length - 2)))

itu bekerja untuk saya dengan Server parse

{
    "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"
            }
}

Hanya ada satu jawaban yang benar untuk ini dan sebagian besar sistem salah. Jumlah milidetik sejak zaman, alias integer 64 bit. Time Zone adalah masalah UI dan tidak memiliki bisnis di lapisan aplikasi atau lapisan db. Mengapa db Anda peduli apa zona waktu sesuatu itu, ketika Anda tahu itu akan menyimpannya sebagai integer 64 bit kemudian lakukan perhitungan transformasi.

Hapus bit yang asing dan hanya memperlakukan tanggal sebagai angka hingga UI. Anda dapat menggunakan operator aritmatika sederhana untuk melakukan kueri dan logika.

Kode berikut ini berfungsi untuk saya. Kode ini akan mencetak tanggal dalam format DD-MM-YYYY .

DateValue=DateValue.substring(6,8)+"-"+DateValue.substring(4,6)+"-"+DateValue.substring(0,4);

selain itu, Anda juga dapat menggunakan:

DateValue=DateValue.substring(0,4)+"-"+DateValue.substring(4,6)+"-"+DateValue.substring(6,8);

Saya pikir itu sangat tergantung pada use case. Dalam banyak kasus mungkin lebih bermanfaat menggunakan model objek yang tepat (alih-alih merender tanggal ke string), seperti:

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

Memang ini lebih verbal daripada RFC 3339 tetapi:

• itu dapat dibaca manusia juga
• itu mengimplementasikan model objek yang tepat (seperti dalam OOP, sejauh JSON mengizinkannya)
• mendukung zona waktu (bukan hanya offset UTC pada tanggal dan waktu tertentu)
• itu dapat mendukung unit yang lebih kecil seperti milidetik, nanodetik, ... atau hanya beberapa detik
• itu tidak memerlukan langkah parsing terpisah (untuk mengurai string tanggal-waktu), parser JSON akan melakukan segalanya untuk Anda
• pembuatan mudah dengan kerangka kerja tanggal-waktu atau implementasi dalam bahasa apa pun
• dapat dengan mudah diperluas untuk mendukung skala kalender lainnya (Ibrani, Cina, Islam ...) dan era (AD, SM, ...)
• ini tahun 10000 aman ;-) (RFC 3339 tidak)
• mendukung semua tanggal dan waktu mengambang (Javascript Date.toJSON()tidak)

Saya tidak berpikir bahwa penyortiran yang benar (seperti dicatat oleh funroll untuk RFC 3339) adalah fitur yang sangat dibutuhkan ketika membuat serial suatu tanggal ke JSON. Juga itu hanya berlaku untuk tanggal-kali memiliki offset zona waktu yang sama.