Le «bon» format de date JSON

J'ai vu tellement de normes différentes pour le format de date JSON:

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

Lequel est le bon? Ou mieux? Existe-t-il une sorte de norme à ce sujet?

JSON lui - même ne spécifie pas comment les dates doivent être représentées, mais JavaScript le fait.

Vous devez utiliser le format émis par Datedes » toJSONméthode:

2012-04-23T18:25:43.511Z

Voici pourquoi:

1. C'est lisible par l'homme mais aussi succinct

2. Il trie correctement

3. Il comprend des secondes fractionnaires, ce qui peut aider à rétablir la chronologie

4. Il est conforme à ISO 8601

5. ISO 8601 est bien établie à l'échelle internationale depuis plus d'une décennie

6. ISO 8601 est approuvée par W3C , RFC3339 et XKCD

Cela étant dit , chaque bibliothèque de dates jamais écrite peut comprendre "millisecondes depuis 1970". Donc, pour une portabilité facile, ThiefMaster a raison.

JSON ne sait rien des dates. Ce que fait .NET est un hack / extension non standard.

J'utiliserais un format qui peut être facilement converti en Dateobjet en JavaScript, c'est-à-dire qui peut être transmis new Date(...). Le format le plus simple et probablement le plus portable est l'horodatage contenant des millisecondes depuis 1970.

Il n'y a pas de bon format ; La spécification JSON ne spécifie pas de format pour l'échange de dates, c'est pourquoi il y a tellement de façons différentes de le faire.

Le meilleur format est sans doute une date représentée au format ISO 8601 ( voir Wikipedia ); il s'agit d'un format bien connu et largement utilisé qui peut être géré dans de nombreuses langues différentes, ce qui le rend très bien adapté à l'interopérabilité. Si vous contrôlez le json généré, par exemple, vous fournissez des données à d'autres systèmes au format json, choisir 8601 comme format d'échange de date est un bon choix.

Si vous n'avez pas de contrôle sur le json généré, par exemple, vous êtes le consommateur de json de plusieurs systèmes existants différents, la meilleure façon de gérer cela est d'avoir une fonction utilitaire d'analyse de date pour gérer les différents formats attendus.

De RFC 7493 (le format de message I-JSON) :

I-JSON signifie Internet JSON ou Interoperable JSON, selon qui vous demandez.

Les protocoles contiennent souvent des éléments de données conçus pour contenir des horodatages ou des durées. Il est RECOMMANDÉ que tous ces éléments de données soient exprimés sous forme de valeurs de chaîne au format ISO 8601, comme spécifié dans la RFC 3339 , avec les restrictions supplémentaires que les majuscules plutôt que les lettres minuscules soient utilisées, que le fuseau horaire soit inclus non par défaut et que les secondes de fin facultatives être inclus même lorsque leur valeur est "00". Il est également RECOMMANDÉ que tous les éléments de données contenant des durées de temps soient conformes à la "durée" de production dans l'annexe A de la RFC 3339, avec les mêmes restrictions supplémentaires.

Juste pour référence, j'ai vu ce format utilisé:

Date.UTC(2017,2,22)

Il fonctionne avec JSONP qui est pris en charge par la $.getJSON()fonction. Je ne suis pas sûr que j'irais jusqu'à recommander cette approche ... en la jetant simplement comme une possibilité parce que les gens le font de cette façon.

FWIW: N'utilisez jamais de secondes depuis l'époque dans un protocole de communication, ni de millisecondes depuis l'époque, car celles-ci sont lourdes de danger grâce à l'implémentation aléatoire des secondes intercalaires (vous ne savez pas si l'expéditeur et le destinataire implémentent correctement les secondes intercalaires UTC).

Une sorte de haine pour les animaux de compagnie, mais beaucoup de gens croient que l'UTC n'est que le nouveau nom de GMT - faux! Si votre système n'implémente pas de secondes intercalaires, vous utilisez GMT (souvent appelé UTC bien qu'il soit incorrect). Si vous implémentez complètement les secondes intercalaires, vous utilisez vraiment UTC. Les secondes intercalaires futures ne peuvent être connues; ils sont publiés par l'IERS selon les besoins et nécessitent des mises à jour constantes. Si vous exécutez un système qui tente d'implémenter des secondes intercalaires mais contient une table de référence obsolète (plus courante que vous ne le pensez), vous n'avez ni GMT, ni UTC, vous avez un système bancal prétendant être UTC.

Ces compteurs de date ne sont compatibles que lorsqu'ils sont exprimés dans un format décomposé (y, m, d, etc.). Ils ne sont JAMAIS compatibles dans un format d'époque. Garde cela à l'esprit.

En cas de doute, accédez simplement à la console Web javascript d'un navigateur moderne en appuyant sur F12 (Ctrl + K dans Firefox) et écrivez ce qui suit:

new Date().toISOString()

Sortira:

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

Ta-da !!

Je crois que le meilleur format pour l'interopérabilité universelle n'est pas la chaîne ISO-8601, mais plutôt le format utilisé par EJSON:

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

Comme décrit ici: https://docs.meteor.com/api/ejson.html

Avantages

1. Analyser les performances: si vous stockez des dates sous forme de chaînes ISO-8601, c'est très bien si vous attendez une valeur de date sous ce champ particulier, mais si vous avez un système qui doit déterminer les types de valeurs sans contexte, vous analysez chaque chaîne pour un format de date.
2. Pas besoin de validation de la date: vous n'avez pas à vous soucier de la validation et de la vérification de la date. Même si une chaîne correspond au format ISO-8601, il peut ne pas s'agir d'une date réelle; cela ne peut jamais arriver avec une date EJSON.
3. Déclaration de type sans ambiguïté: en ce qui concerne les systèmes de données génériques, si vous souhaitez stocker une chaîne ISO en tant que chaîne dans un cas, et une date système réelle dans un autre, les systèmes génériques adoptant le format de chaîne ISO-8601 ne le permettront pas, mécaniquement (sans astuces d'échappement ou solutions horribles similaires).

Conclusion

Je comprends qu'un format lisible par l'homme (chaîne ISO-8601) est utile et plus pratique pour 80% des cas d'utilisation, et en effet personne ne devrait jamais être dit de ne pas stocker leurs dates en tant que chaînes ISO-8601 si c'est ce que leurs applications comprendre, mais pour un format de transport universellement accepté qui devrait garantir certaines valeurs à coup sûr des dates, comment pouvons-nous tenir compte de l'ambiguïté et avoir besoin de tant de validation?

JSON lui-même n'a pas de format de date, peu importe comment quelqu'un stocke les dates. Cependant, puisque cette question est balisée avec javascript, je suppose que vous voulez savoir comment stocker les dates javascript dans JSON. Vous pouvez simplement passer une date à la JSON.stringifyméthode, et elle utilisera Date.prototype.toJSONpar défaut, qui à son tour utilise Date.prototype.toISOString( MDN on 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

J'ai également trouvé utile d'utiliser le reviverparamètre de JSON.parse( MDN sur JSON.parse ) pour convertir automatiquement les chaînes ISO en dates javascript chaque fois que je lis les chaînes JSON.

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

La manière préférée utilise 2018-04-23T18:25:43.511Z...

L'image ci-dessous montre pourquoi c'est la manière préférée:

Donc, comme vous le voyez, Date a une méthode native toJSON, qui returndans ce format et peut être facilement convertie à Datenouveau ...

Dans Sharepoint 2013, obtenir des données en JSON, il n'y a pas de format pour convertir la date en format date uniquement, car cette date doit être au format ISO

yourDate.substring(0,10)

Cela peut vous être utile

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

La date est représentée dans un format standard et triable qui représente une heure UTC (indiquée par le Z). ISO 8601 prend également en charge les fuseaux horaires en remplaçant la valeur Z par + ou - pour le décalage de fuseau horaire:

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

Il existe d'autres variantes du codage du fuseau horaire dans la spécification ISO 8601, mais le format –10: 00 est le seul format TZ pris en charge par les analyseurs JSON actuels. En général, il est préférable d'utiliser le format UTC (Z), sauf si vous avez un besoin spécifique de déterminer le fuseau horaire dans lequel la date a été produite (possible uniquement dans la génération côté serveur).

NB: var date = new Date (); console.log (date); // mer.01 janv.2014 13:28:56 GMT- 1000 (heure standard hawaïenne)

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

pour vous dire que c'est la manière préférée même si JavaScript n'a pas de format standard

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

Si vous utilisez Kotlin, cela résoudra votre problème. (Format MS Json)

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

c'est du travail pour moi avec 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"
            }
}

Il n'y a qu'une seule bonne réponse à cela et la plupart des systèmes se trompent. Nombre de millisecondes depuis l'époque, alias un entier 64 bits. Le fuseau horaire est une préoccupation d'interface utilisateur et n'a aucune activité dans la couche application ou la couche db. Pourquoi votre base de données se soucie-t-elle du fuseau horaire de quelque chose, quand vous savez qu'il va le stocker en tant qu'entier 64 bits, puis faites les calculs de transformation.

Supprimez les bits superflus et traitez simplement les dates comme des nombres jusqu'à l'interface utilisateur. Vous pouvez utiliser des opérateurs arithmétiques simples pour effectuer des requêtes et de la logique.

Le code suivant a fonctionné pour moi. Ce code imprimera la date au format JJ-MM-AAAA .

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

sinon, vous pouvez également utiliser:

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

Je pense que cela dépend vraiment du cas d'utilisation. Dans de nombreux cas, il pourrait être plus avantageux d'utiliser un modèle d'objet approprié (au lieu de rendre la date à une chaîne), comme ceci:

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

Certes, c'est plus verbeux que RFC 3339 mais:

• c'est aussi lisible par l'homme
• il implémente un modèle d'objet approprié (comme dans la POO, dans la mesure où JSON le permet)
• il prend en charge les fuseaux horaires (pas seulement le décalage UTC à la date et à l'heure données)
• il peut prendre en charge des unités plus petites comme les millisecondes, les nanosecondes, ... ou simplement des secondes fractionnaires
• il ne nécessite pas d'étape d'analyse distincte (pour analyser la chaîne date-heure), l'analyseur JSON fera tout pour vous
• création facile avec n'importe quel cadre date-heure ou implémentation dans n'importe quelle langue
• peut facilement être étendu pour prendre en charge d'autres échelles de calendrier (hébreu, chinois, islamique ...) et des époques (AD, BC, ...)
• c'est l'année 10000 en sécurité ;-) (RFC 3339 ne l'est pas)
• prend en charge les dates et les heures flottantes toute la journée (Javascript Date.toJSON()n'est pas le cas)

Je ne pense pas que le tri correct (comme noté par funroll pour RFC 3339) soit une fonctionnalité vraiment nécessaire lors de la sérialisation d'une date en JSON. Cela n'est également vrai que pour les dates-heures ayant le même décalage de fuseau horaire.