javascript - ejemplo - json.parse array

El formato de fecha JSON "correcto"

Question

He visto tantos estándares diferentes para el formato de fecha 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

¿Cuál es la correcta? O mejor? ¿Hay algún tipo de estándar en esto?

Answer 1

Creo que eso realmente depende del caso de uso. En muchos casos, podría ser más beneficioso usar un modelo de objeto adecuado (en lugar de representar la fecha en una cadena), así:

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

Es cierto que esto es más detallado que el RFC 3339 pero:

• también es legible para humanos
• implementa un modelo de objeto adecuado (como en OOP, en la medida en que JSON lo permite)
• admite zonas horarias (no solo el desplazamiento UTC en la fecha y hora especificadas)
• Puede soportar unidades más pequeñas como milisegundos, nanosegundos, ... o simplemente segundos fraccionarios.
• no requiere un paso de análisis por separado (para analizar la cadena de fecha y hora), el analizador JSON hará todo por ti
• Fácil creación con cualquier marco o implementación de fecha y hora en cualquier idioma.
• se puede ampliar fácilmente para admitir otras escalas de calendario (hebreo, chino, islámico ...) y eras (AD, BC, ...)
• es seguro para el año 10000 ;-) (RFC 3339 no lo es)
• admite fechas de todo el día y tiempos de flotación ( Date.toJSON() Javascript no)

No creo que la clasificación correcta (como lo señala funroll para RFC 3339) sea una característica que realmente se necesita cuando se serializa una fecha a JSON. También eso es cierto solamente para las fechas y horas que tienen el mismo desplazamiento de zona horaria.

Answer 2

Desde RFC 7493 (el formato de mensaje I-JSON) :

I-JSON significa Internet JSON o Interoperable JSON, dependiendo de a quién le preguntes.

Los protocolos a menudo contienen elementos de datos que están diseñados para contener marcas de tiempo o duraciones de tiempo. Se RECOMIENDA que todos estos elementos de datos se expresen como valores de cadena en formato ISO 8601, como se especifica en RFC 3339 , con las restricciones adicionales de mayúsculas en lugar de mayúsculas, que la zona horaria se incluya no predeterminada y que los segundos finales opcionales ser incluido incluso cuando su valor es "00". También se RECOMIENDA que todos los elementos de datos que contienen duraciones de tiempo se ajusten a la producción de "duración" en el Apéndice A de RFC 3339, con las mismas restricciones adicionales.

Answer 3

El siguiente código me ha funcionado. Este código imprimirá la fecha en formato DD-MM-YYYY .

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

De lo contrario, también puede utilizar:

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

Answer 4

En Sharepoint 2013, al obtener datos en JSON, no hay un formato para convertir la fecha en un formato de fecha solamente, porque en esa fecha debe estar en formato ISO

yourDate.substring(0,10)

Esto puede ser útil para usted

Answer 5

JSON no sabe nada de fechas. Lo que hace .NET es un hack / extensión no estándar.

Utilizaría un formato que se puede convertir fácilmente en un objeto Date en JavaScript, es decir, uno que se puede pasar a una new Date(...) . El formato más fácil y probablemente el más portátil es la marca de tiempo que contiene milisegundos desde 1970.

Answer 6

Solo hay una respuesta correcta para esto y la mayoría de los sistemas se equivocan. Número de milisegundos desde la época, también conocido como un entero de 64 bits. La zona horaria es una preocupación de la interfaz de usuario y no tiene ningún negocio en la capa de aplicación o la capa de base de datos. ¿Por qué le importa a tu db qué zona horaria es algo? Cuando sabes que se va a almacenar como un entero de 64 bits, haz los cálculos de transformación.

Elimine los bits extraños y simplemente trate las fechas como números hasta la interfaz de usuario. Puedes usar operadores aritméticos simples para hacer consultas y lógica.

Answer 7

Solo por referencia he visto este formato utilizado:

Date.UTC(2017,2,22)

Funciona con JSONP, que es compatible con la función $.getJSON() . No estoy seguro de que vaya tan lejos como para recomendar este enfoque ... simplemente desechándolo como una posibilidad porque la gente lo está haciendo de esta manera.

FWIW: nunca utilice segundos desde la época en un protocolo de comunicación, ni milisegundos desde la época, ya que estos están llenos de peligro gracias a la implementación aleatoria de segundos de salto (no tiene idea si el emisor y el receptor implementan correctamente los segundos de salto UTC).

Es una especie de odio de las mascotas, pero muchas personas creen que UTC es solo el nuevo nombre para GMT, ¡mal! Si su sistema no implementa segundos de salto, entonces está usando GMT (a menudo llamado UTC a pesar de ser incorrecto). Si implementa completamente los segundos de salto, realmente está utilizando UTC. Los segundos de salto futuros no pueden ser conocidos; El IERS los publica según sea necesario y requieren actualizaciones constantes. Si está ejecutando un sistema que intenta implementar segundos de salto pero que contiene una tabla de referencia desactualizada (más común de lo que podría pensar), entonces no tiene GMT ni UTC, tiene un sistema novedoso que pretende ser UTC.

Estos contadores de fecha solo son compatibles cuando se expresan en un formato desglosado (y, m, d, etc.). NUNCA son compatibles en un formato de época. Mantenlo en mente.

Answer 8

es un trabajo para mi servidor parse

{
    "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"
            }
}

Answer 9

JSON no especifica cómo deben representarse las fechas, pero sí lo hace JavaScript.

Debe usar el formato emitido por el método toJSON Date :

2012-04-23T18:25:43.511Z

Este es el por qué:

1. Es legible para los humanos pero también breve.

2. Se ordena correctamente

3. Incluye segundos fraccionarios, que pueden ayudar a restablecer la cronología.

4. Cumple con la norma ISO 8601.

5. ISO 8601 se ha establecido internacionalmente por más de una década.

6. ISO 8601 está avalada por W3C , RFC3339 y XKCD

Dicho esto , todas las bibliotecas de fechas jamás escritas pueden comprender "milisegundos desde 1970". Así que para una fácil portabilidad, ThiefMaster tiene razón.

Answer 10

No hay formato correcto ; La especificación JSON no especifica un formato para el intercambio de fechas, por eso hay tantas formas diferentes de hacerlo.

El mejor formato es posiblemente una fecha representada en formato ISO 8601 ( ver Wikipedia ); Es un formato bien conocido y ampliamente utilizado y puede manejarse en muchos idiomas diferentes, lo que lo hace muy adecuado para la interoperabilidad. Si tiene control sobre el json generado, por ejemplo, proporciona datos a otros sistemas en formato json, elegir 8601 como formato de intercambio de fecha es una buena opción.

Si no tiene control sobre el json generado, por ejemplo, usted es el consumidor de json de varios sistemas existentes diferentes, la mejor manera de manejar esto es tener una función de utilidad de análisis de fecha para manejar los diferentes formatos esperados.