El formato de fecha JSON" correcto"

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

Usaría un formato que se puede convertir fácilmente a un objeto Date en JavaScript, es decir, uno que se puede 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 ; El Especificación JSON no especifica un formato para el intercambio de fechas, por lo que hay tantas formas diferentes de hacerlo.

El mejor formato es posiblemente una fecha representada en formato ISO 8601 (véase Wikipedia ); es un formato bien conocido y ampliamente utilizado y puede ser manejado en muchos idiomas diferentes, lo que lo hace muy adecuado para la interoperabilidad. Si usted tiene control sobre el generado json, 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, 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 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 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 datos los elementos se expresarán como valores de cadena en formato ISO 8601, según se especifique in RFC 3339 , with the additional restrictions that uppercase rather que se utilicen letras minúsculas, que se incluya la zona horaria no por defecto, y que los segundos finales opcionales se incluyen incluso cuando su valor es "00". También SE RECOMIENDA que todos los elementos de datos que contengan duraciones de tiempo conformes a la producción de "duración" en Apéndice A de la 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 soportado por la función $.getJSON(). No estoy seguro de que vaya tan lejos como para recomendar este enfoque... simplemente lanzarlo por ahí 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 cargados de peligro gracias a la implementación aleatoria de segundos intercalares (no tiene idea de si el remitente y el receptor implementan correctamente los segundos intercalares UTC).

Una especie de odio a las mascotas, pero muchas personas creen que UTC es solo el nuevo nombre para GMT wrong ¡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 intercalares, realmente está utilizando UTC. Los segundos intercalares futuros no se pueden conocer; losERS los publican según sea necesario y requieren actualizaciones constantes. Si usted es ejecutar 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 torcido 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 epoch. Ten eso en mente.

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

yourDate.substring(0,10)

Esto puede ser útil para usted

El siguiente código ha funcionado para mí. 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);

Solo hay una respuesta correcta a esto y la mayoría de los sistemas se equivocan. Número de milisegundos desde epoch, también conocido como un entero de 64 bits. La zona horaria es un problema de 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 su base de datos qué zona horaria es algo, cuando sabe que va a almacenarlo como un entero de 64 bits y luego hacer 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 utilizar operadores aritméticos simples para hacer consultas y lógica.

Es trabajo 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"
            }
}

Creo que eso realmente depende del caso de uso. En muchos casos, podría ser más beneficioso usar un modelo de objetos adecuado (en lugar de representar la fecha en una cadena), como 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 objetos apropiado (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 soportar más pequeños unidades como milisegundos, nanosegundos,... o simplemente segundos fraccionados
• 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 lenguaje
• se puede extender fácilmente para soportar otras escalas de calendario (hebreo, chino, Islámico ...) and 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 Date.toJSON() no lo hace)

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