Ik heb zoveel verschillende standaarden gezien voor de JSON-datumnotatie:
"\"\\/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
Welke is de juiste? Of het beste? Is hier een standaard voor?
Antwoord 1, autoriteit 100%
JSONzelf geeft nietaan hoe datums moeten worden weergegeven , maar JavaScript wel.
U moethet formaat gebruiken dat wordt uitgezonden door Date‘s toJSONmethode:
2012-04-23T18:25:43.511Z
Dit is waarom:
-
Het is leesbaar voor mensen, maar ook beknopt
-
Het sorteert correct
-
Het bevat fractionele seconden, wat kan helpen de chronologie te herstellen
-
Het voldoet aan ISO 8601
-
ISO 8601 is al meer dan tien jaar internationaal goed ingeburgerd
Dat gezegd hebbende, kan elke databibliotheek die ooit is geschreven “milliseconden sinds 1970” begrijpen. Dus voor gemakkelijke draagbaarheid heeft ThiefMastergelijk.
Antwoord 2, autoriteit 6%
JSON weet niets over datums. Wat .NET doet is een niet-standaard hack/extensie.
Ik zou een formaat gebruiken dat gemakkelijk kan worden geconverteerd naar een Date-object in JavaScript, dat wil zeggen een formaat dat kan worden doorgegeven aan new Date(...). Het gemakkelijkste en waarschijnlijk meest draagbare formaat is het tijdstempel met milliseconden sinds 1970.
Antwoord 3, autoriteit 2%
Er is geen juiste indeling; De JSON-specificatiespecificeert geen formaat voor het uitwisselen van datums, daarom zijn er zo veel verschillende manieren om het te doen.
Het beste formaat is waarschijnlijk een datum weergegeven in ISO 8601-formaat(zie Wikipedia); het is een bekend en veelgebruikt formaat en kan in veel verschillende talen worden gebruikt, waardoor het zeer geschikt is voor interoperabiliteit. Als je controle hebt over de gegenereerde json, bijvoorbeeld, geef je gegevens aan andere systemen in json-formaat, dan is het een goede keuze om 8601 te kiezen als het formaat voor datumuitwisseling.
Als je bijvoorbeeld geen controle hebt over de gegenereerde json, je bent de gebruiker van json van verschillende bestaande systemen, dan is de beste manier om hiermee om te gaan het hebben van een hulpprogramma voor het ontleden van datums om de verschillende verwachte formaten te verwerken.
Antwoord 4
Van RFC 7493 (The I-JSON Message Format):
I-JSON staat voor Internet JSON of Interoperable JSON, afhankelijk van wie je het vraagt.
Protocollen bevatten vaak gegevensitems die zijn ontworpen om
tijdstempels of tijdsduren. Het wordt AANBEVOLEN dat al dergelijke gegevens
items worden uitgedrukt als tekenreekswaarden in ISO 8601-indeling, zoals gespecificeerd
in RFC 3339, met de aanvullende beperkingen dat hoofdletters eerder
dan kleine letters worden gebruikt, dat de tijdzone niet wordt opgenomen
standaard, en dat optionele volgseconden worden opgenomen, zelfs wanneer
hun waarde is “00”. Het wordt ook AANBEVOLEN dat alle gegevensitems:
met tijdsduren conform de “duur” productie in
Bijlage A van RFC 3339, met dezelfde aanvullende beperkingen.
Antwoord 5
Ter referentie, ik heb dit formaat gebruikt:
Date.UTC(2017,2,22)
Het werkt met JSONPdie wordt ondersteund door de functie $.getJSON(). Ik weet niet zeker of ik zo ver zou gaan om deze aanpak aan te bevelen… ik gooi het gewoon weg als een mogelijkheid omdat mensen het op deze manier doen.
FWIW:Gebruik nooit seconden sinds epoche in een communicatieprotocol, noch milliseconden sinds epoche, omdat deze vol gevaar zijn dankzij de gerandomiseerde implementatie van schrikkelseconden (je hebt geen idee of zender en ontvanger beide correct implementeren UTC schrikkelseconden).
Een soort huisdierenhaat, maar veel mensen geloven dat UTC gewoon de nieuwe naam is voor GMT — verkeerd! Als uw systeem geen schrikkelseconden implementeert, gebruikt u GMT (vaak UTC genoemd ondanks dat dit onjuist is). Als u schrikkelseconden volledig implementeert, gebruikt u echt UTC. Toekomstige schrikkelseconden zijn niet bekend; ze worden indien nodig gepubliceerd door de IERS en vereisen constante updates. Als je een systeem gebruikt dat schrikkelseconden probeert te implementeren, maar een verouderde referentietabel bevat (komt vaker voor dan je zou denken), dan heb je noch GMT, noch UTC, je hebt een wankel systeem dat zich voordoet als UTC.
Deze datumtellers zijn alleen compatibel als ze worden uitgedrukt in een uitgesplitst formaat (y, m, d, enz.). Ze zijn NOOIT compatibel in een tijdperk-formaat. Houd dat in gedachten.
Antwoord 6
Ga bij twijfel gewoon naar de javascript-webconsole van een moderne browser door op F12te drukken (Ctrl+Shift+K in Firefox) en schrijf het volgende:
new Date().toISOString()
Zal uitvoeren:
“2019-07-04T13:33:03.969Z”
Ta-da!!
Antwoord 7
JSON zelf heeft geen datumnotatie, het maakt niet uit hoe iemand datums opslaat. Aangezien deze vraag echter is getagd met javascript, neem ik aan dat u wilt weten hoe u javascript-datums in JSON opslaat. Je kunt gewoon een datum doorgeven aan de JSON.stringify-methode, en deze zal standaard Date.prototype.toJSONgebruiken, die op zijn beurt Date.prototype.toISOString(MDN op 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
Ik vond het ook handig om de parameter revivervan JSON.parsete gebruiken (MDN op JSON.parse) om ISO-strings automatisch terug te converteren naar javascript-datums wanneer ik JSON-strings lees.
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...
Antwoord 8
In Sharepoint 2013, het verkrijgen van gegevens in JSON, is er geen formaat om de datum om te zetten in een alleen-datum-formaat, omdat die datum in ISO-formaat zou moeten zijn
yourDate.substring(0,10)
Dit kan nuttig voor je zijn
Antwoord 9
De voorkeur gaat uit naar het gebruik van 2018-04-23T18:25:43.511Z…
De afbeelding hieronder laat zien waarom dit de voorkeur heeft:
Zoals je ziet heeft Date dus een native methode toJSON, die returnin dit formaat en gemakkelijk weer kan worden geconverteerd naar Date.. .
Antwoord 10
Ik geloof dat de beste indeling voor universele interoperabiliteitniet de ISO-8601-tekenreeks is, maar eerder de indeling die door EJSON wordt gebruikt:
{ "myDateField": { "$date" : <ms-since-epoch> } }
Zoals hier beschreven: https://docs.meteor.com/api/ejson.html
Voordelen
- Prestatie parseren:als u datums opslaat als ISO-8601-tekenreeksen, is dit geweldig als u een datumwaarde verwacht onder dat specifieke veld, maar als u een systeem hebt dat waardetypes moet bepalen zonder context, je analyseert elke string voor een datumnotatie.
- Geen datumvalidatie nodig:u hoeft zich geen zorgen te maken over validatie en verificatie van de datum. Zelfs als een tekenreeks overeenkomt met het ISO-8601-formaat, is het misschien geen echte datum; dit kan nooit gebeuren met een EJSON-datum.
- Eenduidige typeverklaring:voor zover generieke gegevenssystemen gaan, als u in één geval een ISO-tekenreeks als een tekenreeksen een echte systeemdatumin een ander, generieke systemen die het ISO-8601-tekenreeksformaat gebruiken, zullen dit mechanisch niet toestaan (zonder ontsnappingstrucs of soortgelijke vreselijke oplossingen).
Conclusie
Ik begrijp dat een door mensen leesbaar formaat (ISO-8601-tekenreeks) nuttig en handigeris voor 80% van de gebruiksgevallen, en inderdaad mag niemand ooit verteld worden nietom hun datums op te slaan als ISO-8601-strings als dat is wat hun applicaties begrijpen, maarvoor een universeel geaccepteerd transportformaat dat moet garanderen dat bepaalde waarden zekerdatums zijn , hoe kunnen we dubbelzinnigheid toestaan en zoveel validatie nodig hebben?
Antwoord 11
“2014-01-01T23:28:56.782Z”
De datum wordt weergegeven in een standaard en sorteerbaar formaat dat een UTC-tijd vertegenwoordigt (aangegeven door de Z). ISO 8601 ondersteunt ook tijdzones door de Z te vervangen door + of – waarde voor de tijdzone-offset:
“2014-02-01T09:28:56.321-10:00”
Er zijn andere variaties van de tijdzonecodering in de ISO 8601-specificatie, maar het –10:00-formaat is het enige TZ-formaat dat de huidige JSON-parsers ondersteunen. Over het algemeen is het het beste om het op UTC gebaseerde formaat (Z) te gebruiken, tenzij u een specifieke behoefte heeft om de tijdzone te achterhalen waarin de datum is geproduceerd (alleen mogelijk bij het genereren aan de serverzijde).
NB:
var date = new Date();
console.log(date); // Wed Jan 01 2014 13:28:56 GMT-
1000 (Hawaiian Standard Time)
var json = JSON.stringify(date);
console.log(json); // "2014-01-01T23:28:56.782Z"
Om je te vertellen dat dit de beste manier is, ook al heeft JavaScript er geen standaardformaat voor
// 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
Antwoord 12
het is werk voor mij met 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"
}
}
Antwoord 13
Er is hier maar één juist antwoord op en de meeste systemen hebben het bij het verkeerde eind. Aantal milliseconden sinds epoche, oftewel een 64-bits geheel getal. Tijdzone is een UI-zorg en heeft geen zaken in de app-laag of db-laag. Waarom maakt het je db uit welke tijdzone iets is, als je weet dat het het als een 64-bits geheel getal gaat opslaan, voer dan de transformatieberekeningen uit.
Verwijder de overbodige bits en behandel datums als getallen tot aan de gebruikersinterface. U kunt eenvoudige rekenkundige operatoren gebruiken om query’s en logica uit te voeren.
Antwoord 14
De volgende code heeft voor mij gewerkt. Deze code drukt de datum af in de indeling DD-MM-YYYY.
DateValue=DateValue.substring(6,8)+"-"+DateValue.substring(4,6)+"-"+DateValue.substring(0,4);
anders kun je ook gebruiken:
DateValue=DateValue.substring(0,4)+"-"+DateValue.substring(4,6)+"-"+DateValue.substring(6,8);
Antwoord 15
Ik denk dat dat echt afhangt van het gebruik. In veel gevallen kan het voordeliger zijn om een juist objectmodel te gebruiken (in plaats van de datum naar een string te vertalen), zoals:
{
"person" :
{
"name" : {
"first": "Tom",
"middle": "M",
...
}
"dob" : {
"year": 2012,
"month": 4,
"day": 23,
"hour": 18,
"minute": 25,
"second": 43,
"timeZone": "America/New_York"
}
}
}
Toegegeven, dit is uitgebreider dan RFC 3339, maar:
- het is ook leesbaar voor mensen
- het implementeert een juist objectmodel (zoals in OOP, voor zover JSON dit toestaat)
- het ondersteunt tijdzones (niet alleen de UTC-offset op de opgegeven datum en tijd)
- het kan kleinere eenheden ondersteunen, zoals milliseconden, nanoseconden, … of gewoon fractionele seconden
- het vereist geen aparte parseerstap (om de datum-tijd-string te ontleden), de JSON-parser doet alles voor je
- eenvoudige creatie met elk datum-tijd-framework of implementatie in elke taal
- kan eenvoudig worden uitgebreid om andere kalenderschalen (Hebreeuws, Chinees, islamitisch …) en tijdperken (AD, BC, …) te ondersteunen
- het is het jaar 10000 veilig 😉 (RFC 3339 niet)
- ondersteunt de hele dag datums en zwevende tijden (Javascript’s
Date.toJSON()niet)
Ik denk niet dat correct sorteren (zoals opgemerkt door funroll voor RFC 3339) een functie is die echt nodig is bij het serialiseren van een datum naar JSON. Dat geldt ook alleen voor datum-tijden met dezelfde afwijking van de tijdzone.