Das „richtige“ JSON-Datumsformat

Ich habe so viele verschiedene Standards für das JSON-Datumsformat gesehen:

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

Welches ist das richtige? Oder am besten? Gibt es einen Standard dafür?

JSON selbst nicht , wie Datumsangaben dargestellt werden sollen, JavaScript jedoch.

Sie sollten das Format verwenden, das von Dateder toJSONMethode ausgegeben wird :

2012-04-23T18:25:43.511Z

Hier ist der Grund:

1. Es ist menschlich lesbar, aber auch prägnant

2. Es sortiert richtig

3. Es enthält Sekundenbruchteile, mit deren Hilfe die Chronologie wiederhergestellt werden kann

4. Es entspricht ISO 8601

5. ISO 8601 ist seit mehr als einem Jahrzehnt international etabliert

6. ISO 8601 wird von W3C , RFC3339 und XKCD empfohlen

Abgesehen davon kann jede Datumsbibliothek, die jemals geschrieben wurde, "Millisekunden seit 1970" verstehen. Für eine einfache Portabilität ist ThiefMaster also richtig.

JSON weiß nichts über Daten. Was .NET tut, ist ein nicht standardmäßiger Hack / eine nicht standardmäßige Erweiterung.

Ich würde ein Format verwenden, das leicht in ein DateObjekt in JavaScript konvertiert werden kann , dh eines, an das übergeben werden kann new Date(...). Das einfachste und wahrscheinlich portabelste Format ist der Zeitstempel, der seit 1970 Millisekunden enthält.

Es gibt kein richtiges Format ; Die JSON-Spezifikation gibt kein Format für den Austausch von Daten an, weshalb es so viele verschiedene Möglichkeiten gibt.

Das beste Format ist wohl ein Datum, das im ISO 8601-Format dargestellt wird ( siehe Wikipedia ). Es ist ein bekanntes und weit verbreitetes Format und kann in vielen verschiedenen Sprachen verarbeitet werden, wodurch es sich sehr gut für die Interoperabilität eignet. Wenn Sie beispielsweise die Kontrolle über den generierten JSON haben, stellen Sie Daten anderen Systemen im JSON-Format zur Verfügung. Die Auswahl von 8601 als Datumsaustauschformat ist eine gute Wahl.

Wenn Sie beispielsweise keine Kontrolle über das generierte JSON haben, sind Sie der Konsument von JSON aus mehreren vorhandenen Systemen. Die beste Möglichkeit, dies zu handhaben, besteht darin, eine Dienstprogrammfunktion zur Datumsanalyse zu verwenden, um die verschiedenen erwarteten Formate zu verarbeiten.

Aus RFC 7493 (Das I-JSON-Nachrichtenformat) :

I-JSON steht entweder für Internet JSON oder Interoperable JSON, je nachdem, wen Sie fragen.

Protokolle enthalten häufig Datenelemente, die Zeitstempel oder Zeitdauern enthalten sollen. Es wird EMPFOHLEN, dass alle diese Datenelemente als Zeichenfolgenwerte im ISO 8601-Format ausgedrückt werden, wie in RFC 3339 angegeben , mit den zusätzlichen Einschränkungen, dass Groß- und Kleinbuchstaben verwendet werden, dass die Zeitzone nicht standardmäßig enthalten ist und dass optionale nachfolgende Sekunden eingeschlossen werden, auch wenn ihr Wert "00" ist. Es wird auch EMPFOHLEN, dass alle Datenelemente, die Zeitdauern enthalten, mit denselben zusätzlichen Einschränkungen der Produktion "Dauer" in Anhang A von RFC 3339 entsprechen.

Nur als Referenz habe ich dieses Format verwendet gesehen:

Date.UTC(2017,2,22)

Es funktioniert mit JSONP, das von der $.getJSON()Funktion unterstützt wird . Ich bin mir nicht sicher, ob ich diesen Ansatz empfehlen würde ... wirf ihn einfach als Möglichkeit raus, weil die Leute es so machen.

FWIW: Verwenden Sie niemals Sekunden seit der Epoche in einem Kommunikationsprotokoll oder Millisekunden seit der Epoche, da diese dank der zufälligen Implementierung von Schaltsekunden mit Gefahren behaftet sind (Sie haben keine Ahnung, ob Sender und Empfänger UTC-Schaltsekunden ordnungsgemäß implementieren).

Eine Art Haustierhass, aber viele Leute glauben, dass UTC nur der neue Name für GMT ist - falsch! Wenn Ihr System keine Schaltsekunden implementiert, verwenden Sie GMT (oft als UTC bezeichnet, obwohl es falsch ist). Wenn Sie Schaltsekunden vollständig implementieren, verwenden Sie tatsächlich UTC. Zukünftige Schaltsekunden können nicht bekannt sein. Sie werden bei Bedarf von der IERS veröffentlicht und müssen ständig aktualisiert werden. Wenn Sie ein System ausführen, das versucht, Schaltsekunden zu implementieren, aber eine veraltete Referenztabelle enthält (häufiger als Sie vielleicht denken), haben Sie weder GMT noch UTC. Sie haben ein Wonky-System, das vorgibt, UTC zu sein.

Diese Datumszähler sind nur kompatibel, wenn sie in einem aufgeschlüsselten Format (y, m, d usw.) ausgedrückt werden. Sie sind NIEMALS in einem Epochenformat kompatibel. Merk dir das.

Im Zweifelsfall rufen Sie einfach die Javascript-Webkonsole eines modernen Browsers auf, indem Sie F12 (Strg + K in Firefox) drücken, und schreiben Sie Folgendes:

new Date().toISOString()

Wird ausgegeben:

2019-07-04T13: 33: 03.969Z

Ta-da !!

Ich glaube, dass das beste Format für universelle Interoperabilität nicht die ISO-8601-Zeichenfolge ist, sondern das von EJSON verwendete Format:

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

Wie hier beschrieben: https://docs.meteor.com/api/ejson.html

Leistungen

1. Analyseleistung: Wenn Sie Datumsangaben als ISO-8601-Zeichenfolgen speichern, ist dies ideal, wenn Sie einen Datumswert in diesem bestimmten Feld erwarten. Wenn Sie jedoch über ein System verfügen, das Werttypen ohne Kontext bestimmen muss, analysieren Sie jede Zeichenfolge für a Datumsformat.
2. Keine Datumsüberprüfung erforderlich : Sie müssen sich keine Gedanken über die Validierung und Überprüfung des Datums machen. Selbst wenn eine Zeichenfolge dem ISO-8601-Format entspricht, handelt es sich möglicherweise nicht um ein echtes Datum. Dies kann mit einem EJSON-Datum niemals passieren.
3. Eindeutige Typdeklaration: Wenn generische Datensysteme in einem Fall eine ISO-Zeichenfolge als Zeichenfolge und in einem anderen Fall ein reales Systemdatum speichern möchten , lassen generische Systeme, die das ISO-8601-Zeichenfolgenformat verwenden, dies mechanisch nicht zu (ohne Fluchttricks oder ähnliche schreckliche Lösungen).

Fazit

Ich verstehe , dass ein lesbares Format (ISO-8601 string) ist nützlich und bequem für 80% der Anwendungsfälle, und in der Tat niemand jemals gesagt wird , nicht ihre Daten als ISO-8601 - Strings zu speichern , wenn das ist , was ihre Anwendungen verstehen, aber für eine allgemein anerkannte Transportformat , die auf bestimmte Werte garantieren sollte sicher Daten sein, wie können wir für Mehrdeutigkeit und Notwendigkeit für so viel Validierung ermöglichen?

JSON selbst hat kein Datumsformat, es ist egal, wie jemand Daten speichert. Da diese Frage jedoch mit Javascript gekennzeichnet ist, möchten Sie vermutlich wissen, wie Javascript-Daten in JSON gespeichert werden. Sie können einfach ein Datum an die JSON.stringifyMethode übergeben, und es wird Date.prototype.toJSONstandardmäßig verwendet, das wiederum verwendet Date.prototype.toISOString( MDN auf 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

Ich fand es auch nützlich, den reviverParameter JSON.parse( MDN auf JSON.parse ) zu verwenden, um ISO-Zeichenfolgen automatisch wieder in Javascript-Daten zu konvertieren, wenn ich JSON-Zeichenfolgen lese.

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

Der bevorzugte Weg ist die Verwendung von 2018-04-23T18:25:43.511Z...

Das Bild unten zeigt, warum dies der bevorzugte Weg ist:

Wie Sie sehen, hat Date eine native Methode toJSON, die returnin diesem Format problemlos wieder konvertiert Datewerden kann ...

In Sharepoint 2013 gibt es beim Abrufen von Daten in JSON kein Format zum Konvertieren des Datums in das Nur-Datum-Format, da in diesem Datum das ISO-Format vorliegen sollte

yourDate.substring(0,10)

Dies kann für Sie hilfreich sein

2014-01-01T23: 28: 56.782Z

Das Datum wird in einem standardmäßigen und sortierbaren Format dargestellt, das eine UTC-Zeit darstellt (angezeigt durch das Z). ISO 8601 unterstützt auch Zeitzonen, indem das Z durch den Wert + oder - für den Zeitzonenversatz ersetzt wird:

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

Es gibt andere Variationen der Zeitzonencodierung in der ISO 8601-Spezifikation, aber das Format –10: 00 ist das einzige TZ-Format, das aktuelle JSON-Parser unterstützen. Im Allgemeinen ist es am besten, das UTC-basierte Format (Z) zu verwenden, es sei denn, Sie müssen die Zeitzone ermitteln, in der das Datum erstellt wurde (nur bei der serverseitigen Generierung möglich).

NB: var date = new Date (); console.log (Datum); // Mi Jan 01 2014 13:28:56 GMT-1000 (hawaiianische Standardzeit)

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

um Ihnen zu sagen, dass dies der bevorzugte Weg ist, obwohl JavaScript kein Standardformat dafür hat

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

Wenn Sie Kotlin verwenden, wird dies Ihr Problem lösen. (MS Json-Format)

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

Es ist Arbeit für mich mit Parse Server

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

Es gibt nur eine richtige Antwort darauf und die meisten Systeme verstehen es falsch. Anzahl der Millisekunden seit der Epoche, auch bekannt als 64-Bit-Ganzzahl. Die Zeitzone ist ein Problem der Benutzeroberfläche und hat nichts mit der App- oder DB-Ebene zu tun. Warum kümmert es Ihre Datenbank, welche Zeitzone etwas ist, wenn Sie wissen, dass es als 64-Bit-Ganzzahl gespeichert wird, führen Sie dann die Transformationsberechnungen durch.

Entfernen Sie die überflüssigen Bits und behandeln Sie Datumsangaben als Zahlen bis zur Benutzeroberfläche. Sie können einfache arithmetische Operatoren verwenden, um Abfragen und Logik auszuführen.

Der folgende Code hat bei mir funktioniert. Dieser Code druckt das Datum im Format TT-MM-JJJJ .

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

Andernfalls können Sie auch Folgendes verwenden:

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

Ich denke, das hängt wirklich vom Anwendungsfall ab. In vielen Fällen kann es vorteilhafter sein, ein geeignetes Objektmodell zu verwenden (anstatt das Datum in eine Zeichenfolge zu rendern), wie folgt:

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

Zugegeben, dies ist ausführlicher als RFC 3339, aber:

• Es ist auch für Menschen lesbar
• Es implementiert ein geeignetes Objektmodell (wie in OOP, soweit JSON dies zulässt).
• Es unterstützt Zeitzonen (nicht nur den UTC-Offset zum angegebenen Datum und zur angegebenen Uhrzeit).
• Es kann kleinere Einheiten wie Millisekunden, Nanosekunden ... oder einfach Sekundenbruchteile unterstützen
• Es ist kein separater Parsing-Schritt erforderlich (um die Datums- / Zeitzeichenfolge zu analysieren). Der JSON-Parser erledigt alles für Sie
• Einfache Erstellung mit einem beliebigen Datums- / Zeitrahmen oder einer Implementierung in einer beliebigen Sprache
• kann leicht erweitert werden, um andere Kalenderskalen (Hebräisch, Chinesisch, Islamisch ...) und Epochen (AD, BC, ...) zu unterstützen.
• es ist Jahr 10000 sicher ;-) (RFC 3339 ist nicht)
• unterstützt ganztägige Daten und Gleitzeiten (Javascript Date.toJSON()nicht)

Ich denke nicht, dass die korrekte Sortierung (wie von funroll für RFC 3339 angegeben) eine Funktion ist, die wirklich benötigt wird, wenn ein Datum in JSON serialisiert wird. Dies gilt auch nur für Datums- und Uhrzeitangaben mit demselben Zeitzonenversatz.