"Doğru" JSON tarih biçimi

JSON tarih biçimi için çok farklı standartlar gördüm:

"\"\\/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

Hangisi doğru olanı? Yoksa en iyisi mi? Bu konuda herhangi bir standart var mı?

JSON kendisi vermez tarihleri temsil şeklini belirtmek, ancak JavaScript yapar.

Sen gerektiğini yaydığı biçimini kullanan Datebireyin toJSONyöntemiyle:

2012-04-23T18:25:43.511Z

İşte nedeni:

1. İnsan tarafından okunabilir ama aynı zamanda özlü

2. Doğru sıralar

3. Kronolojinin yeniden oluşturulmasına yardımcı olabilecek kesirli saniyeleri içerir

4. ISO 8601'e uygundur

5. ISO 8601, on yıldan fazla bir süredir uluslararası alanda köklü bir konuma sahiptir

6. ISO 8601, W3C , RFC3339 ve XKCD tarafından onaylanmıştır

Bununla birlikte , şimdiye kadar yazılan her tarih kütüphanesi "1970'den beri milisaniye" anlayabilir. Kolay taşınabilirlik için ThiefMaster haklı.

JSON tarihler hakkında hiçbir şey bilmiyor. .NET'in yaptığı, standart olmayan bir hack / eklentidir.

DateJavaScript'te bir nesneye, yani geçirilebilen bir nesneye kolayca dönüştürülebilen bir format kullanırdım new Date(...). En kolay ve muhtemelen en taşınabilir biçim 1970'den bu yana milisaniye içeren zaman damgasıdır.

Doğru biçim yoktur ; JSON şartname bunu yapmak için çok farklı yolları vardır yüzden tarihleri alışverişi için bir format belirtmez.

En iyi biçim tartışmalı olarak ISO 8601 biçiminde temsil edilen bir tarihtir ( Wikipedia'ya bakın ); iyi bilinen ve yaygın olarak kullanılan bir biçimdir ve birçok farklı dilde kullanılabilir, bu da birlikte çalışabilirlik için çok uygundur. Örneğin, oluşturulan json üzerinde kontrolünüz varsa, json biçimindeki diğer sistemlere veri sağlarsınız, tarih değişimi formatı olarak 8601'i seçerek iyi bir seçimdir.

Oluşturulan json üzerinde kontrolünüz yoksa, örneğin, birkaç farklı mevcut sistemden json tüketicisiyseniz, bunun en iyi yolu, beklenen farklı formatları işlemek için bir tarih ayrıştırma yardımcı programı işlevine sahip olmaktır.

Gönderen RFC 7493 (I-JSON İleti Biçimi) :

I-JSON, kime sorduğunuza bağlı olarak Internet JSON veya Birlikte Çalışabilir JSON anlamına gelir.

Protokoller genellikle zaman damgalarını veya süreleri içerecek şekilde tasarlanmış veri öğeleri içerir. Bu tür tüm veri öğelerinin, RFC 3339'da belirtildiği gibi ISO 8601 biçiminde dize değerleri olarak , küçük harfler yerine büyük harflerin kullanıldığı, zaman diliminin varsayılan olarak eklenmeyeceği ve isteğe bağlı son saniye olarak ifade edilmesi ÖNERİLİR değerleri "00" olsa bile dahil edilmelidir. Ayrıca, zaman sürelerini içeren tüm veri öğelerinin, RFC 3339 Ek A'daki "süre" üretimine ve aynı ek kısıtlamalara uyması ÖNERİLİR.

Sadece referans için bu formatın kullanıldığını gördüm:

Date.UTC(2017,2,22)

Fonksiyon tarafından desteklenen JSONP ile çalışır $.getJSON(). Bu yaklaşımı önerecek kadar ileri gideceğime emin değilim ... sadece bunu bir olasılık olarak dışarı atmak çünkü insanlar bunu böyle yapıyorlar.

FWIW: Artık bir iletişim protokolünde dönemden bu yana saniye, ne de dönemden bu yana milisaniye kullanmayın, çünkü artık saniyelerin rasgele uygulanması sayesinde bunlar tehlikeyle doludur (gönderenin ve alıcının UTC artık saniyelerini doğru bir şekilde uygulayıp uygulamadığı hakkında hiçbir fikriniz yoktur).

Bir tür evcil hayvan nefreti var, ancak birçok insan UTC'nin GMT için yeni isim olduğuna inanıyor - yanlış! Sisteminiz artık saniye uygulamıyorsa, GMT kullanıyorsunuzdur (yanlış olmasına rağmen genellikle UTC olarak adlandırılır). Artık saniyeleri tam olarak uygularsanız gerçekten UTC kullanıyorsunuz demektir. Gelecekteki artık saniye bilinemez; IERS tarafından gerektiğinde yayınlanır ve sürekli güncellemeler gerektirir. Artık saniyeler uygulamayı deneyen ancak güncel olmayan ve referans tablosu içeren (düşündüğünüzden daha yaygın) bir sistem çalıştırıyorsanız, ne GMT ne de UTC'ye sahipsiniz, UTC gibi davranan sakat bir sisteminiz var.

Bu tarih sayaçları yalnızca bozuk biçimde (y, m, d vb.) İfade edildiğinde uyumludur. Hiçbir zaman bir epoch formatında uyumlu değildirler. Bunu aklınızda bulundurun.

Şüphe duyduğunuzda, F12'ye (Firefox'ta Ctrl + K) basarak modern bir tarayıcının javascript web konsoluna gidin ve aşağıdakileri yazın:

new Date().toISOString()

Çıktı olacak:

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

Ta-da !!

Evrensel birlikte çalışabilirlik için en iyi biçimin ISO-8601 dizesi değil, EJSON tarafından kullanılan biçim olduğuna inanıyorum:

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

Burada açıklandığı gibi: https://docs.meteor.com/api/ejson.html

Yararları

1. Performansı ayrıştırma: Tarihleri ​​ISO-8601 dizeleri olarak depolarsanız, belirli bir alanın altında bir tarih değeri bekliyorsanız bu harikadır, ancak bağlam olmadan değer türlerini belirlemesi gereken bir sisteminiz varsa, tarih formatı.
2. Tarih Doğrulama Gerekmiyor: Tarihin doğrulanması ve doğrulanması konusunda endişelenmenize gerek yok. Bir dize ISO-8601 biçimiyle eşleşse bile, gerçek bir tarih olmayabilir; bu asla bir EJSON tarihiyle olamaz.
3. Belirsiz Tür Bildirimi: Genel veri sistemleri söz konusu olduğunda, bir ISO dizesini bir durumda dize olarak saklamak istiyorsanız ve başka bir sistemde gerçek bir sistem tarihi ISO-8601 dize biçimini benimseyen genel sistemlere buna mekanik olarak izin vermez (kaçış hileleri veya benzeri korkunç çözümler olmadan).

Sonuç

Bir insanın okuyabileceği format (ISO-8601 dize) yararlı ve fazla olduğunu anlamak uygun kullanım durumları% 80'i için, ve aslında hiç kimse söylenmesi gerekir değil ISO-8601 dizeleri olarak kendi tarihlerini depolamak için bunu en ne onların uygulamaları ise anlamak ancak belirli değerleri güvence altına alan bir evrensel olarak kabul görmüş taşıma biçimi için kesin bu kadar çok doğrulama için belirsizlik ve ihtiyacı için izin nasıl tarihleri olmak?

JSON'un tarih formatı yoktur, kimsenin tarihleri ​​nasıl sakladığı umurumda değildir. Ancak, bu soru javascript ile etiketlendiğinden, javascript tarihlerini JSON'da nasıl saklayacağınızı bilmek istediğinizi varsayalım. JSON.stringifyYönteme yalnızca bir tarih iletebilirsiniz ve Date.prototype.toJSONvarsayılan olarak kullanılır Date.prototype.toISOString( sırayla kullanır ( Date.toJSON'da MDN ):

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

Ben de JSON dizeleri her okuduğunuzda otomatik olarak ISO dizeleri javascript tarihlerine dönüştürmek için ( JSON.parse MDN ) reviverparametresini kullanmak için yararlı buldum .JSON.parse

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...

Tercih edilen yöntem 2018-04-23T18:25:43.511Z...

Aşağıdaki resim, bunun neden tercih edilen yol olduğunu göstermektedir:

Yani tarihi bir yerli Yöntemi sahiptir gördüğümüz gibi toJSON, returnve bu biçimde kolayca dönüştürülebilir Datetekrar ...

Sharepoint 2013'te, JSON'da veri almanın, tarihi yalnızca tarih biçimine dönüştürecek bir biçimi yoktur, çünkü bu tarihte ISO biçiminde olmalıdır

yourDate.substring(0,10)

Bu sizin için yararlı olabilir

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

Tarih, UTC saatini (Z ile gösterilir) temsil eden standart ve sıralanabilir bir biçimde temsil edilir. ISO 8601, Z'yi saat dilimi farkı için + veya - değeriyle değiştirerek saat dilimlerini de destekler:

"2014-02-01T09: 28: 56,321-10: 00"

ISO 8601 spesifikasyonunda saat dilimi kodlamasının başka varyasyonları vardır, ancak –10: 00 formatı, mevcut JSON ayrıştırıcılarının desteklediği tek TZ formatıdır. Genel olarak, tarihin üretildiği saat dilimini bulmaya özel bir gereksiniminiz yoksa (yalnızca sunucu tarafı oluşturmada mümkündür) UTC tabanlı biçimi (Z) kullanmak en iyisidir.

Not: var tarih = yeni Tarih (); console.log (tarih); // Çar 01 Ocak 2014 13:28:56 GMT- 1000 (Hawaii Standart Saati)

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

JavaScript bunun için standart bir biçime sahip olmamasına rağmen bunun tercih edilen yol olduğunu söylemek için

// 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

Kotlin kullanıyorsanız, bu sorununuzu çözecektir. (MS Json biçimi)

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

benim için ayrıştırma sunucusu ile çalışmak

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

Bunun tek bir doğru cevabı var ve çoğu sistem yanlış anlıyor. Dönemden bu yana geçen milisaniye sayısı, yani 64 bit tam sayı. Saat Dilimi bir kullanıcı arayüzü sorunudur ve uygulama katmanında veya db katmanında hiç iş yoktur. Neden db bir şey ne zaman dilimi umurumda, 64 bit tamsayı olarak saklayacağını bildiğiniz zaman dönüşüm hesaplamaları yapmak.

Yabancı bitleri çıkarın ve tarihleri ​​UI'ye kadar sayılar olarak ele alın. Basit aritmetik işleçleri sorgu ve mantık yapmak için kullanabilirsiniz.

Aşağıdaki kod benim için çalıştı. Bu kod, tarihi GG-AA-YYYY biçiminde yazdırır .

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

aksi takdirde şunları da kullanabilirsiniz:

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

Bunun gerçekten kullanım durumuna bağlı olduğunu düşünüyorum. Birçok durumda, (örneğin bir dizeye tarih vermek yerine) uygun bir nesne modeli kullanmak daha yararlı olabilir:

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

Kuşkusuz bu RFC 3339'dan daha ayrıntılı ancak:

• insan tarafından okunabilir
• uygun bir nesne modeli uygular (JSON'un izin verdiği ölçüde OOP'ta olduğu gibi)
• saat dilimlerini destekler (yalnızca belirtilen tarih ve saatteki UTC ofsetini değil)
• milisaniye, nanosaniye, ... veya sadece kesirli saniye gibi daha küçük birimleri destekleyebilir
• ayrı bir ayrıştırma adımı gerektirmez (tarih-saat dizesini ayrıştırmak için), JSON ayrıştırıcısı sizin için her şeyi yapar
• herhangi bir tarih-zaman çerçevesi veya herhangi bir dilde uygulama ile kolay oluşturma
• diğer takvim ölçeklerini (İbranice, Çince, İslami ...) ve dönemleri (AD, BC, ...) desteklemek için kolayca genişletilebilir
• 10000 yıl güvenli ;-) (RFC 3339 değil)
• tüm gün tarihlerini ve kayan süreleri destekler (Javascriptler desteklemez Date.toJSON())

Doğru sıralama (RFC 3339 için funroll tarafından belirtildiği gibi) JSON bir tarih serileştirirken gerçekten gerekli bir özellik olduğunu sanmıyorum. Ayrıca bu yalnızca aynı saat dilimi uzaklığına sahip tarih saatleri için geçerlidir.