El formato de fecha JSON "correcto"

He visto muchos 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?

JSON en sí no especifica cómo se deben representar las fechas, pero JavaScript sí.

Usted debe utilizar el formato emitido por Date's toJSONmétodo:

2012-04-23T18:25:43.511Z

Este es el por qué:

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

2. Se ordena correctamente

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

4. Cumple con ISO 8601

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

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

Dicho esto , cada biblioteca de fechas jamás escrita puede comprender "milisegundos desde 1970". Entonces, para una fácil portabilidad, ThiefMaster tiene razón.

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

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

No hay un formato correcto ; La especificación JSON no especifica un formato para intercambiar fechas, razón por la cual hay tantas formas diferentes de hacerlo.

El mejor formato es posiblemente una fecha representada en formato ISO 8601 ( ver Wikipedia ); Es un formato muy 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, eligiendo 8601 como formato de intercambio de fechas es una buena opción.

Si no tiene control sobre el json generado, por ejemplo, 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 fechas para manejar los diferentes formatos esperados.

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

I-JSON significa JSON de Internet o JSON interoperable, dependiendo de a quién le pregunte.

Los protocolos a menudo contienen elementos de datos 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 que se utilicen letras mayúsculas en lugar de minúsculas, que la zona horaria se incluya no predeterminada y que los segundos finales opcionales se incluirá incluso cuando su valor sea "00". También se RECOMIENDA que todos los elementos de datos que contengan 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.

Solo como referencia, he visto este formato utilizado:

Date.UTC(2017,2,22)

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

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

Una especie de odio a las mascotas, pero muchas personas creen que UTC es solo el nuevo nombre de GMT, ¡mal! Si su sistema no implementa segundos intercalares, entonces está utilizando GMT (a menudo llamado UTC a pesar de ser incorrecto). Si implementa completamente los segundos bisiestos, realmente está utilizando UTC. Los segundos de salto futuros no se pueden conocer; IERS los publica según sea necesario y requieren actualizaciones constantes. Si está ejecutando un sistema que intenta implementar segundos intercalares pero 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 inestable que finge ser UTC.

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

En caso de duda, simplemente vaya a la consola web javascript de un navegador moderno presionando F12 (Ctrl + K en Firefox) y escriba lo siguiente:

new Date().toISOString()

Saldrá:

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

Ta-da !!

Creo que el mejor formato para la interoperabilidad universal no es la cadena ISO-8601, sino el formato utilizado por EJSON:

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

Como se describe aquí: https://docs.meteor.com/api/ejson.html

Beneficios

1. Análisis del rendimiento: si almacena fechas como cadenas ISO-8601, esto es excelente si espera un valor de fecha en ese campo en particular, pero si tiene un sistema que debe determinar los tipos de valores sin contexto, está analizando cada cadena para un formato de fecha.
2. No es necesario validar la fecha : no debe preocuparse por la validación y verificación de la fecha. Incluso si una cadena coincide con el formato ISO-8601, puede que no sea una fecha real; Esto nunca puede suceder con una fecha EJSON.
3. Declaración de tipo inequívoca: en lo que respecta a los sistemas de datos genéricos, si desea almacenar una cadena ISO como una cadena en un caso, y una fecha real del sistema en otro, los sistemas genéricos que adopten el formato de cadena ISO-8601 no lo permitirán, mecánicamente (sin trucos de escape o soluciones horribles similares).

Conclusión

Entiendo que un formato legible por humanos (cadena ISO-8601) es útil y más conveniente para el 80% de los casos de uso, y de hecho a nadie se le debe decir que no almacene sus fechas como cadenas ISO-8601 si eso es lo que hacen sus aplicaciones entender, pero para un formato de transporte universalmente aceptado que debe garantizar a ciertos valores para asegurarse de que las fechas, ¿cómo podemos permitir la ambigüedad y la necesidad de que tanto la validación?

JSON en sí no tiene formato de fecha, no le importa cómo alguien almacene las fechas. Sin embargo, dado que esta pregunta está etiquetada con JavaScript, supongo que desea saber cómo almacenar las fechas de JavaScript en JSON. Simplemente puede pasar una fecha al JSON.stringifymétodo, y usará Date.prototype.toJSONde forma predeterminada, que a su vez usa Date.prototype.toISOString( MDN en 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

También me pareció útil usar el reviverparámetro JSON.parse( MDN en JSON.parse ) para convertir automáticamente las cadenas ISO a fechas de JavaScript cada vez que leía cadenas 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 forma preferida es usar 2018-04-23T18:25:43.511Z...

La siguiente imagen muestra por qué esta es la forma preferida:

Como puede ver, Date tiene un método nativo toJSON, que returnen este formato se puede convertir fácilmente de Datenuevo ...

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

yourDate.substring(0,10)

Esto puede ser útil para usted.

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

La fecha se representa en un formato estándar y ordenable que representa una hora UTC (indicada por la Z). ISO 8601 también admite zonas horarias al reemplazar la Z con el valor + o - para el desplazamiento de la zona horaria:

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

Existen otras variaciones de la codificación de zona horaria en la especificación ISO 8601, pero el formato –10: 00 es el único formato TZ que admiten los analizadores JSON actuales. En general, es mejor usar el formato basado en UTC (Z) a menos que tenga una necesidad específica de averiguar la zona horaria en la que se produjo la fecha (posible solo en la generación del lado del servidor).

NB: fecha var = nueva fecha (); console.log (fecha); // Mié 01 Ene 2014 13:28:56 GMT- 1000 (Hora estándar de Hawai)

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

para decirte que esa es la forma preferida a pesar de que JavaScript no tiene un formato estándar para ello

// 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 está utilizando Kotlin, esto resolverá su problema. (Formato MS Json)

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

es trabajo para mí con el servidor de análisis

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

Solo hay una respuesta correcta a 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 UI y no tiene negocios en la capa de aplicación o en la capa de base de datos. ¿Por qué a tu db le importa qué zona horaria es algo? Cuando sabes que lo 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. Puede usar operadores aritméticos simples para hacer consultas y lógica.

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

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

de lo contrario, también puede usar:

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

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), de esta manera:

{
"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 RFC 3339 pero:

• es legible por humanos también
• implementa un modelo de objeto adecuado (como en OOP, siempre que JSON lo permita)
• admite zonas horarias (no solo el desplazamiento UTC en la fecha y hora indicadas)
• 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 usted
• Creación fácil con cualquier marco de fecha-hora o implementación 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 flotantes (Javascript Date.toJSON()no)

No creo que la clasificación correcta (como lo señala funroll para RFC 3339) sea una característica realmente necesaria cuando se serializa una fecha en JSON. Además, eso solo es cierto para las fechas y horas que tienen el mismo desplazamiento de zona horaria.