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

 yourDate.substring(0,10)

Esto puede ser útil para usted

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

• también es legible por humanos
• implementa un modelo de objeto adecuado (como en OOP, en la medida en que JSON lo permita)
• admite zonas horarias (no solo el desplazamiento UTC en la fecha y hora dadas)
• puede admitir unidades más pequeñas como milisegundos, nanosegundos... o simplemente fracciones de segundo
• no requiere un paso de análisis separado (para analizar la cadena de fecha y hora), el analizador JSON hará todo por usted
• fácil creación con cualquier marco de fecha y 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 el año 10000 seguro ;-) (RFC 3339 no lo es)
• admite fechas de todo el día y tiempos flotantes (Javascript's Date.toJSON() no lo hace)

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

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 número entero de 64 bits. La zona horaria es una preocupación de la interfaz de usuario y no tiene nada que ver con la capa de la aplicación o la capa de la base de datos. ¿Por qué le importa a su base de datos qué zona horaria es algo, cuando sabe que lo almacenará como un número entero de 64 bits y luego hará los cálculos de transformación?

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

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

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

2012-04-23T18:25:43.511Z

Este es el por qué:

1. Es legible por humanos pero también sucinto.

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 ha sido bien establecida internacionalmente por más de una década

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

Dicho esto , cada biblioteca de fechas jamás escrita puede entender "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 objeto Date en JavaScript, es decir, uno que se pueda pasar a 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 el intercambio de fechas, por lo que existen tantas formas diferentes de hacerlo.

Podría decirse que el mejor formato es una fecha representada en formato ISO 8601 ( ver Wikipedia ); es un formato bien conocido y ampliamente utilizado y se puede manejar en muchos lenguajes 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 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 fecha para manejar los diferentes formatos esperados.

Solo como referencia, he visto este formato utilizado:

 Date.UTC(2017,2,22)

Funciona con JSONP , que es compatible con la $.getJSON() . No estoy seguro de ir tan lejos como para recomendar este enfoque... simplemente lo descarto 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 peligros gracias a la implementación aleatoria de segundos intercalares (no tiene idea si el remitente y el receptor implementan correctamente los segundos intercalares UTC).

Una especie de odio favorito, pero muchas personas creen que UTC es solo el nuevo nombre para GMT, ¡incorrecto! Si su sistema no implementa segundos bisiestos, entonces está usando GMT (a menudo llamado UTC a pesar de ser incorrecto). Si implementa completamente los segundos bisiestos, realmente está usando UTC. Los futuros segundos intercalares no se pueden conocer; son publicados por el IERS según sea necesario y requieren actualizaciones constantes. Si está ejecutando un sistema que intenta implementar segundos bisiestos 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 (y, m, d, etc). NUNCA son compatibles en un formato de época. Mantenlo en mente.

funciona para mí con 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" } }

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 puedes usar:

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

La forma preferida es usar 2018-04-23T18:25:43.511Z ...

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

Entonces, como puede ver, Date tiene un método nativo para toJSON , que return en este formato y se puede convertir fácilmente a Date nuevamente ...

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. Rendimiento de análisis: 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 tipos de valor sin contexto, está analizando cada cadena para un formato de fecha.
2. Sin necesidad de validación de fecha: no necesita preocuparse por la validación y verificación de la fecha. Incluso si una cadena coincide con el formato ISO-8601, es posible que no sea una fecha real; esto nunca puede suceder con una fecha EJSON.
3. Declaración de tipo inequívoco: 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 adoptan 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, nunca se le debe decir a nadie que no almacene sus fechas como cadenas ISO-8601 si eso es lo que sus aplicaciones entiendo, pero para un formato de transporte universalmente aceptado que debería garantizar ciertos valores para ser fechas seguras , ¿cómo podemos permitir la ambigüedad y la necesidad de tanta validación?

"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 un valor + o - para el desplazamiento de la zona horaria:

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

Hay otras variaciones de la codificación de la 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 (es posible solo en la generación del lado del servidor).

NÓTESE BIEN:

 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"

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

JSON en sí mismo no tiene formato de fecha, no le importa cómo alguien almacena las fechas. Sin embargo, dado que esta pregunta está etiquetada con javascript, supongo que desea saber cómo almacenar fechas de javascript en JSON. Simplemente puede pasar una fecha al método JSON.stringify , y usará Date.prototype.toJSON de manera 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 encontré útil usar el parámetro reviver de JSON.parse ( MDN en JSON.parse ) para convertir automáticamente las cadenas ISO a fechas de javascript cada vez que leo 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...

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

 new Date().toISOString()

Saldrá:

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

Ta-da!!

No hay un formato correcto; La especificación JSON no especifica un formato para el intercambio de fechas

No hay un formato correcto; La especificación JSON no especifica un formato para el intercambio de fechas

Si estas consumindo una api de un tercero verifica la documentacion de su api a ver si tienes algun error en ella o tiene un formato definida para en envio del campo

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

I-JSON significa Internet JSON o Interoperable JSON, según a quién le pregunte.

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 que se usen letras mayúsculas en lugar de minúsculas, que la zona horaria se incluya sin valores predeterminados y que los segundos finales opcionales incluirse aun 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.