Question Le "bon" format de date JSON


J'ai vu tellement de standards différents 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? Y a-t-il une sorte de norme à ce sujet?


840
2018-04-23 18:32


origine


Réponses:


JSON se ne fait pas Précisez comment les dates doivent être représentées, mais JavaScript le fait.

Toi devrait utiliser le format émis par Datede toJSON mé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 fractionnées, ce qui peut aider à rétablir la chronologie

  4. Il est conforme à ISO 8601

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

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

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


1370
2018-04-11 15:20



JSON ne sait rien des dates. Qu'est-ce que .NET fait est un hack / extension non standard.

Je voudrais utiliser un format qui peut être facilement converti en un Date objet en JavaScript, c'est-à-dire qui peut être passé à new Date(...). Le format le plus facile et probablement le plus portable est l'horodatage contenant des millisecondes depuis 1970.


103
2018-04-23 18:34



Il n'y a pas de bon format; le 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 dans Format ISO 8601 (voir Wikipedia) C'est un format bien connu et largement utilisé qui peut être manipulé dans plusieurs langues différentes, ce qui le rend très bien adapté à l'interopérabilité. Si vous avez un contrôle sur le fichier json généré, par exemple, vous fournissez des données à d'autres systèmes au format json, en choisissant 8601 car le format d'échange de dates 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 d'analyse de date pour gérer les différents formats attendus.


30
2018-04-23 18:35



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

I-JSON est l'acronyme de JSON Internet ou Interoperable JSON, en fonction de qui vous demandez.

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


19
2018-03-27 18:48



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

Date.UTC(2017,2,22)

Cela fonctionne avec JSONP qui est soutenu par le $.getJSON() fonction. Je ne suis pas sûr d'aller aussi loin que de recommander cette approche ... juste jeter là-bas comme une possibilité parce que les gens le font de cette façon.

FWIW: N'utilisez jamais de secondes depuis une époque dans un protocole de communication, ni de millisecondes depuis l'époque, car elles sont dangereuses grâce à l'implémentation aléatoire des secondes intercalaires (vous ne savez pas si l'émetteur et le récepteur implémentent correctement les secondes intercalaires UTC).

Un peu un animal déteste, mais beaucoup de gens croient que UTC est juste le nouveau nom pour GMT - faux! Si votre système n'implémente pas les secondes intercalaires, alors vous utilisez GMT (souvent appelé UTC bien qu'il soit incorrect). Si vous implémentez complètement les secondes intercalaires, vous utilisez vraiment l'UTC. Les prochaines secondes intercalaires ne peuvent pas être connues. ils sont publiés par l'IERS si nécessaire et nécessitent des mises à jour constantes. Si vous utilisez un système qui tente d'implémenter des secondes intercalaires mais contient une table de référence obsolète (plus commun que vous ne le pensez), alors vous n'avez ni GMT, ni UTC, vous avez un système bancal prétendant être UTC.

Ces compteurs de dates 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.


5
2018-02-27 07:33



Dans Sharepoint 2013, l'obtention de données dans JSON n'existe pas de format pour convertir la date en format date unique, car cette date doit être au format ISO

yourDate.substring(0,10)

Cela peut vous être utile


1
2017-09-16 11:09



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

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);

0
2018-04-10 06:11