Pertanyaan 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 untuk hal ini?


840
2018-04-23 18:32


asal


Jawaban:


JSON diri tidak tentukan bagaimana tanggal harus diwakili, tetapi JavaScript tidak.

Kamu harus gunakan format yang dipancarkan oleh Date's toJSON metode:

2012-04-23T18:25:43.511Z

Inilah alasannya:

  1. Ini bisa dibaca manusia tetapi juga ringkas

  2. Ini mengurutkan dengan benar

  3. Ini termasuk detik-detik pecahan, yang dapat membantu menetapkan kembali kronologi

  4. Itu 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 telah dibilang, setiap perpustakaan tanggal yang pernah ditulis dapat memahami "milidetik sejak 1970". Jadi untuk portabilitas mudah, ThiefMaster benar.


1370
2018-04-11 15:20



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

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


103
2018-04-23 18:34



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

Format terbaik bisa dibilang tanggal yang diwakili Format ISO 8601 (lihat Wikipedia); Ini adalah format yang terkenal dan banyak digunakan dan dapat ditangani di banyak bahasa yang berbeda, 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 sebagai 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 berbeda, cara terbaik untuk menangani ini adalah dengan memiliki fungsi parsing untuk menangani berbagai format yang diharapkan.


30
2018-04-23 18:35



Dari RFC 7493 (Format Pesan I-JSON):

I-JSON adalah singkatan dari JSON Internet atau JSON yang Dapat Dioperasikan, tergantung pada siapa yang Anda tanyakan.

Protokol sering mengandung item data yang dirancang untuk mengandung   cap waktu atau jangka waktu. Ini DIREKOMENDASIKAN bahwa semua data semacam itu   item dinyatakan sebagai nilai string dalam format ISO 8601, sebagaimana ditentukan   di RFC 3339, dengan batasan tambahan yang agak besar   dari huruf kecil digunakan, bahwa zona waktu tidak termasuk   gagal, dan bahwa detik tambahan opsional disertakan bahkan ketika   nilainya adalah "00". Juga DIREKOMENDASIKAN bahwa semua item data   mengandung jangka waktu sesuai dengan produksi "durasi" di   Lampiran A dari RFC 3339, dengan pembatasan tambahan yang sama.


19
2018-03-27 18:48



Hanya untuk referensi saya pernah melihat format ini digunakan:

Date.UTC(2017,2,22)

Ia bekerja dengan JSONP yang didukung oleh $.getJSON() fungsi. Tidak yakin saya akan sejauh ini untuk 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 detik kabisat (Anda tidak tahu apakah pengirim dan penerima baik benar menerapkan detik kabisat UTC).

Jenis kebencian terhadap hewan peliharaan, tetapi banyak orang percaya bahwa UTC hanyalah nama baru untuk GMT - salah! Jika sistem Anda tidak menerapkan detik kabisat maka Anda menggunakan GMT (sering disebut UTC meskipun tidak benar). Jika Anda benar-benar menerapkan detik kabisat, Anda benar-benar menggunakan UTC. Detik lompatan di masa depan tidak dapat diketahui; mereka dipublikasikan oleh IERS seperlunya dan memerlukan pembaruan konstan. Jika Anda menjalankan sistem yang mencoba menerapkan detik kabisat tetapi berisi dan tabel referensi out-of-date (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 diekspresikan dalam format rusak (y, m, d, dll). Mereka TIDAK PERNAH kompatibel dalam format epoch. Ingat itu.


5
2018-02-27 07:33



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

yourDate.substring(0,10)

Ini mungkin bermanfaat untuk Anda


1
2017-09-16 11:09



Kode berikut ini berhasil untuk saya. Kode ini akan mencetak tanggal masuk DD-MM-YYYY format.

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

lain, Anda juga dapat menggunakan:

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

0
2018-04-10 06:11



Hanya ada satu jawaban yang benar untuk ini dan sebagian besar sistem salah. Jumlah milidetik sejak zaman, alias bilangan bulat 64 bit. Time Zone adalah masalah UI dan tidak memiliki bisnis di lapisan aplikasi atau lapisan db. Mengapa db Anda peduli apa zona waktu adalah sesuatu, ketika Anda tahu itu akan menyimpannya sebagai bilangan bulat 64 bit kemudian melakukan 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.


-3
2017-12-16 23:56