Frage 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

Welcher ist der Richtige? Oder am besten? Gibt es irgendeinen Standard dafür?


840
2018-04-23 18:32


Ursprung


Antworten:


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

Sie sollte Verwenden Sie das Format von Dateist es toJSON Methode:

2012-04-23T18:25:43.511Z

Hier ist der Grund:

  1. Es ist lesbar, aber auch prägnant

  2. Es sortiert korrekt

  3. Es enthält Sekundenbruchteile, die helfen können, die Chronologie wiederherzustellen

  4. Es entspricht ISO 8601

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

  6. ISO 8601 wird unterstützt von W3C, RFC3339, und XKCD

Das wird gesagt, jede Datumsbibliothek, die jemals geschrieben wurde, kann "Millisekunden seit 1970" verstehen. Für eine einfache Portabilität hat ThiefMaster also recht.


1370
2018-04-11 15:20



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

Ich würde ein Format verwenden, das leicht in ein umgewandelt werden kann Date Objekt in JavaScript, d. h. eines, an das übergeben werden kann new Date(...). Das einfachste und wahrscheinlich portabelste Format ist der Zeitstempel mit Millisekunden seit 1970.


103
2018-04-23 18:34



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

Das beste Format ist wohl ein Datum in ISO 8601-Format (siehe Wikipedia); Es ist ein bekanntes und weit verbreitetes Format und kann in vielen verschiedenen Sprachen verwendet werden, wodurch es sehr gut für die Interoperabilität geeignet ist. Wenn Sie beispielsweise die Kontrolle über den generierten JSON haben, stellen Sie Daten anderen Systemen im JSON-Format zur Verfügung. Wählen Sie 8601, da das Format des Datumsaustauschs eine gute Wahl ist.

Wenn Sie zum Beispiel keine Kontrolle über den generierten JSON haben, weil Sie der Konsument von JSON aus mehreren verschiedenen existierenden Systemen sind, besteht die beste Möglichkeit, dies zu tun, darin, eine Datumsparsing-Dienstprogrammfunktion für die verschiedenen erwarteten Formate zu haben.


30
2018-04-23 18:35



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

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

Protokolle enthalten häufig Datenelemente, die enthalten sein sollen   Zeitstempel oder Zeitdauern. Es wird EMPFOHLEN, dass alle diese Daten   Elemente werden wie angegeben als Zeichenfolgenwerte im ISO 8601-Format ausgedrückt   im RFC 3339, mit den zusätzlichen Einschränkungen, dass Großbuchstaben eher   als Kleinbuchstaben verwendet werden, dass die Zeitzone nicht enthalten sein soll   voreingestellt, und optionale fakultative Sekunden werden auch dann eingeschlossen, wenn   Ihr Wert ist "00". Es wird auch empfohlen, dass alle Datenelemente   Die Zeitdauern entsprechen der "Dauer" Produktion in   Anhang A von RFC 3339, mit den gleichen zusätzlichen Einschränkungen.


19
2018-03-27 18:48



Nur als Referenz habe ich dieses Format verwendet:

Date.UTC(2017,2,22)

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

FWIW: Verwenden Sie niemals Sekunden seit der Epoche eines Kommunikationsprotokolls, noch Millisekunden seit der Epoche, weil diese durch die randomisierte Implementierung von Schaltsekunden sehr gefährlich sind (Sie haben keine Ahnung, ob Sender und Empfänger beide UTC-Schaltsekunden korrekt umsetzen).

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 auch UTC genannt, obwohl es falsch ist). Wenn Sie Schaltsekunden vollständig implementieren, verwenden Sie wirklich UTC. Zukünftige Schaltsekunden können nicht bekannt sein; Sie werden vom IERS bei Bedarf veröffentlicht und erfordern ständige Aktualisierungen. Wenn Sie ein System ausführen, das versucht, Schaltsekunden zu implementieren, aber eine veraltete Referenztabelle enthält (häufiger als Sie vielleicht denken), dann haben Sie weder ein WEZ noch eine UTC, sondern ein verwackeltes System, das vorgibt, UTC zu sein.

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


5
2018-02-27 07:33



In Sharepoint 2013, Daten in JSON erhalten, gibt es kein Format zum Konvertieren von Datum in nur Datumsformat, da in diesem Datum im ISO-Format sein sollte

yourDate.substring(0,10)

Dies kann für Sie hilfreich sein


1
2017-09-16 11:09



Der folgende Code hat für mich funktioniert. Dieser Code druckt das Datum in DD / MM / JJJJ Format.

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

Ansonsten können Sie auch verwenden:

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

0
2018-04-10 06:11



Es gibt nur eine richtige Antwort darauf und die meisten Systeme machen es falsch. Anzahl der Millisekunden seit der Epoche, aka eine 64-Bit-Ganzzahl. Die Zeitzone ist ein UI-Problem und hat in der App-Schicht oder der Db-Schicht keine Auswirkungen. Warum kümmert sich Ihre Datenbank um die Zeitzone? Wenn Sie wissen, dass sie als 64-Bit-Ganzzahl gespeichert wird, führen Sie die Umwandlungsberechnungen durch.

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


-3
2017-12-16 23:56