Das „richtige“ JSON-Datumsformat

1137

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?

Kamyar Nazeri
quelle
75
In JSON gibt es kein Datumsformat. Es gibt nur Zeichenfolgen, die ein De- / Serializer den Datumswerten zuordnen möchte.
11
strings, numbers, true, false, null, objectsUndarrays
Russ Cam
12
Das in JavaScript integrierte JSON-Objekt und ISO8601 enthalten jedoch alle Informationen, die für Mensch und Computer verständlich sind, und beruhen nicht auf dem Beginn des Computerzeitalters (1970-1-1).
Poussma

Antworten:

1849

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.

Funroll
quelle
32
Dies ist auch die bevorzugte Darstellung nach ECMA :JSON.stringify({'now': new Date()}) "{"now":"2013-10-21T13:28:06.419Z"}"
Steven
11
Ich würde der Liste einen weiteren wichtigen Grund hinzufügen: Sie ist vom Gebietsschema unabhängig. Wenn Sie ein Datum wie den 02.03.2014 hatten, benötigen Sie zusätzliche Informationen, um zu wissen, ob es sich um den 3. Februar oder den 2. März handelt. Dies hängt davon ab, ob das US-Format oder ein anderes Format verwendet wird.
Juanal
107
upvote für das Erwähnen und Verknüpfen von xkcd: D @ajorquera Ich benutze normalerweise momentjs dafür. Ich habe auch Probleme mit IE in dieser Hinsicht gesehen
fholzer
54
Was den zweiten Punkt betrifft, so wird er nach dem Jahr 10000 nicht richtig sortiert. Wir haben jedoch fast 8000 Jahre Zeit, um ein neues Format zu entwickeln, daher ist dies wahrscheinlich kein Problem.
Erfa
7
Eigentlich, @Erfa, da es -vor den Ziffern kommt ASCII, wird es bis zum Jahr 100.000 gut sortieren. ; P
Ben Leggiero
128

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.

DiebMaster
quelle
3
stackoverflow.com/questions/10286385/… - Mal sehen, ob jemand weiß, warum sich FF so verhält.
ThiefMaster
11
Wenn Sie diesen Weg gehen, stellen Sie sicher, dass Sie sich nicht mit Daten vor 1970 befassen müssen!
Ben Dolman
8
Wie @BenDolman sagte, behandelt diese "Lösung" Daten vor dem 1. Januar 1970 (Epoche) nicht angemessen. Es gibt auch einen Grund, warum ISO8601 überhaupt existiert. Hier auf der Erde haben wir Dinge, die "Zeitzonen" genannt werden. Wo ist das in Millisekunden? JSON hat möglicherweise keinen Standard für Datumsangaben, aber Datumsangaben existieren außerhalb von JSON, und dafür gibt es einen Standard. Die Antwort von funroll ist die richtige (siehe auch: xkcd.com/1179 ).
JoeLinux
5
Es ist vielleicht auch erwähnenswert , dass (Milli) Sekunden aus dem Jahr 1970 zu erwähnen , ist nicht vorhersehbar für Termine in der Zukunft , denn wir haben Schaltsekunden . Ich würde es also nicht für die Kommunikation zwischen Prozessen und die Datenspeicherung verwenden. Es ist jedoch hilfreich, es intern in einem Programm zu verwenden, da es in einer einzigen Ganzzahl gespeichert werden kann, was Ihnen einige Leistungsvorteile bietet.
Brodie Garnet
5
Der Unix-Zeitstempel ist immer UTC. Sie konvertieren von Ihrer lokalen Zeitzone, bevor Sie den Zeitstempel generieren, und kehren wieder zur angezeigten lokalen Zeitzone zurück. Dort gibt es keine Mehrdeutigkeit.
lkraider
46

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.

Russ Cam
quelle
2
@mlissner aber das ist eine Meinung , auf das man am besten ist. ISO-8601 ist ein Standard, aber nicht der Standard für JSON (obwohl ich ihn gerne verwenden würde). Microsoft hat beispielsweise beschlossen, es nicht zu verwenden ( msdn.microsoft.com/en-us/library/… ). Die beste Vorgehensweise ist, sich an eine (vernünftige) Konvention zu halten, was auch immer das ist. Wie ich in der Antwort angegeben habe, besteht die beste Möglichkeit, dies zu handhaben, darin, eine Dienstprogrammfunktion zur Datumsanalyse zu definieren, die die erwarteten Formate verarbeiten kann. Wenn Sie in Systeme integrieren, die unterschiedliche Formate verwenden, sollte die Funktion jeden Fall behandeln.
Russ Cam
1
@RussCam, wir können hin und her gehen, aber wenn jemand nach dem besten Weg fragt, Daten in JSON zu codieren, fragt er, wie Daten formatiert werden sollen, wenn er JSON erstellt (und die Antwort lautet im Allgemeinen ISO-8601). Sie beantworten die entgegengesetzte Frage: Wie werden JSON-Daten verwendet, sobald sie bereits erstellt wurden (obwohl Ihr Rat richtig ist)?
mlissner
1
Die JSON-Schemaspezifikation besagt tatsächlich, dass Daten, die von einem Schema überprüft werden, im 8601-Format vorliegen müssen.
Gnasher729
3
@ gnasher729 hast du einen link
Russ Cam
@vallismortis - Dies ist ein Entwurf einer Spezifikation zum Definieren eines Schemas für eine bestimmte zwischen Parteien ausgetauschte JSON-Struktur, nicht das Format für Daten in der JSON-Spezifikation. Ich werde meine Antwort basierend auf den Kommentaren überarbeiten, es scheint nicht, dass ich es klar genug gemacht habe
Russ Cam
27

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.

Bryan Larsen
quelle
2
Dies ist auch das Format, das von Date().toISOString()und Date().toJSON()mit der Einschränkung erzeugt wird , dass Datekein Zeitzonenwert verfolgt wird und daher immer die Zeitstempel in der UTC ( Z) - Zeitzone ausgegeben werden. Der Wert kann mit new Date("...")und analysiert werden Date.parseDate.
Søren Løvborg
15

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.

Tel
quelle
4
Ich würde dieses Format nicht verwenden, aber der Rest der von Ihnen bereitgestellten Informationen ist sehr nützlich, danke!
Robert Mikes
9

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

Shayan Ahmad
quelle
3

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?

Ciabaros
quelle
In dieser Antwort weiter oben im Thread erfahren Sie, warum Millisekunden seit der Epoche Vorbehalte wie eine falsche Berechnung der Schaltsekunden usw. aufweisen: stackoverflow.com/a/42480073/190476
Sie,
@SudhanshuMishra Die Vorbehalte, auf die Sie verweisen, sind allgemeine Fallstricke für äußerst akademische Belange von Unix-Zeitstempeln, die sich hauptsächlich auf die Generierung von Zeitstempeln beziehen. Dies ist bei der Millisekundenauflösung noch weniger von Belang. Wie in einem anderen Kommentar erwähnt, werden die meisten Computerdaten intern als Unix-Zeitstempel dargestellt, auch wenn sie anderweitig verfügbar gemacht und formatiert werden. Nichtsdestotrotz ist an der Millisekunden-Darstellung eines bestimmten Datums und einer bestimmten Uhrzeit nichts auszusetzen, insbesondere im Vergleich zu anderen Ansätzen, die leicht durch dieselben Nano-Vorbehalte unter der Haube beeinträchtigt werden können.
Ciabaros
Nur um Bedenken hinsichtlich "außerhalb des Bereichs liegender" Daten für Unix-Zeitstempel hinzuzufügen: Dies sind Systemspeicherprobleme, die in einem viel breiteren Kontext als dem Transportformat behandelt werden müssen. Zum Beispiel muss dieses Format nicht auf Ganzzahlen beschränkt sein, die in 32 Bit passen, noch muss es streng positive Zahlen sein, aber niemand wird das "Problem des Jahres 2038" lösen, indem er Zeitstempel auf System- / Architekturebene löscht ;; Sie müssen nur erweitert werden (z. B. auf 64-Bit oder höher), und dies hat keinen Einfluss auf dieses vorgeschlagene Transportformat.
Ciabaros
3

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...
Justus Romijn
quelle
2

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

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

JSON-Datum

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

Alireza
quelle
2
Richtig! In der JSON Data Interchange-Syntax wird der Standard nicht angegeben: ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf. In der Praxis sind jedoch ISO 8601-kompatible Formate plattformübergreifend, einschließlich JavaScript-Laufzeit, wünschenswerter.
Kamyar Nazeri
1

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

raghava arr
quelle
0

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
Pedro JR
quelle
0

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)))
suhas sasuke
quelle
-3

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"
            }
}
Kemal Karadag
quelle
-6

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.

Chad Wilson
quelle
Kommentare wurden in den Chat verschoben .
Jon Clements
5
Jetzt haben Sie zwei Probleme: Welche Epoche sollten Sie wählen und welche Millisekunden sollten Sie zählen? Die wahrscheinlich häufigste Wahl ist die Unix-Zeit (1970-01-01T00: 00: 00 UTC und SI-Millisekunden, mit Ausnahme derjenigen, die innerhalb einer Schaltsekunde liegen), aber das macht natürlich zukünftige Zeiten undefiniert.
aij
2
Wie repräsentieren Sie Mikrosekunden? RFC3339 funktioniert mit jeder Präzision einwandfrei. Sie haben einen Reader, der die Zeitzone analysiert und Ihnen den richtigen Zeitstempel sowie zusätzliche Informationen gibt. Kalender-Apps kümmern sich normalerweise um Zeitzonen.
Gnasher729
11
Die Zeitzone ist kein Problem für die Benutzeroberfläche, es sei denn, es macht Ihnen nichts aus, Ihren nächsten Flug zu verpassen. Flüge werden in Ortszeit gebucht und folgen bestimmten Regeln für DST-Änderungen. Den Offset zu verlieren bedeutet, wichtige Geschäftsinformationen zu verlieren
Panagiotis Kanavos
1
Einige weitere Gegenargumente sind die Fähigkeit, Zeiten vor 1970 darzustellen (unter der Annahme dieser bestimmten Epoche) und die Tendenz von JSON, etwas menschlich lesbar zu sein.
Timo
-8

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);
Aniket Kumar Shrivastava
quelle
-19

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.

Marder
quelle
7
Ich bezweifle, dass irgendjemand json im Jahr 10000 verwenden wird, oder sogar, dass zu diesem Zeitpunkt das Jahr 10000 immer noch das Jahr 10000 sein wird. Wenn diese beiden Dinge bis dahin immer noch zutreffen, kann das Format einfach auf eine dreistellige Zahl erweitert werden Jahrhundertkomponente. Ich würde also sagen, die Leute können sicher bei RFC 3339 bleiben, zumindest bis zum Jahr 9900
Erinnerung an einen Traum
8
@downvoters: Laut Warum ist die Abstimmung wichtig? Sie sollten abstimmen, wenn a post contains wrong information, is poorly researched, or fails to communicate information. Bitte erläutern Sie, aus welchem ​​dieser Gründe Sie diese Antwort abgelehnt haben.
Marten
5
@ Marden Zwei Dinge. 1. Ihnen wird niemals eine Erklärung für Abstimmungen geschuldet, obwohl ich verstehe, dass dies hilfreich sein kann. 2. Ich habe Ihre Antwort nicht abgelehnt, aber ich würde vermuten, dass die Leute Ihre Antwort nicht mögen, weil sie denken, dass dies der falsche Weg ist. Das würde es als "falsche Information" qualifizieren, da die Frage nach dem besten Weg sucht, etwas zu tun
Kevin Wells
7
Ich habe Sie nicht abgelehnt, aber ich kann mit Sicherheit verstehen, wie "ein weiteres schlecht spezifiziertes Format erfinden" (was Sie im Grunde sagen) als falsch oder schlecht recherchiert angesehen wird.
aij
2
@Phil, UTC ist nicht wirklich eine Zeitzone (es gibt keinen Ort auf der Erde, der "UTC" als offizielle Zeitzone verwendet), es ist ein Zeitstandard . Auch Zeitzonenversätze sind ziemlich unvorhersehbar. Es gibt keine Möglichkeit zu sagen, ob "12:00 Uhr Moskauer Zeit" im Jahr 2025 noch "9:00 UTC" ist, wie es heute ist. Es wurde in den letzten 30 Jahren einige Male geändert . Wenn Sie eine zukünftige Ortszeit ausdrücken möchten, benötigen Sie echte Zeitzonen.
Marten