Pregunta El formato de fecha JSON "correcto"


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?


840
2018-04-23 18:32


origen


Respuestas:


JSON sí mismo no especifique cómo deben representarse las fechas, pero JavaScript sí.

debería use el formato emitido por Datees toJSON método:

2012-04-23T18:25:43.511Z

Este es el por qué:

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

  2. Se ordena correctamente

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

  4. Se ajusta a ISO 8601

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

  6. ISO 8601 está respaldado por W3C, RFC3339y XKCD

Habiendo dicho eso, cada biblioteca de citas que se haya escrito puede comprender "milisegundos desde 1970". Entonces, para una fácil portabilidad, ThiefMaster tiene razón.


1370
2018-04-11 15:20



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

Usaría un formato que se puede convertir fácilmente en Date objeto 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.


103
2018-04-23 18:34



No hay un formato correcto; los Especificación JSON no especifica un formato para intercambiar fechas por lo que hay muchas maneras 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 que puede manejarse en muchos idiomas diferentes, por lo que es muy adecuado para la interoperabilidad. Si tiene control sobre el json generado, por ejemplo, proporciona datos a otros sistemas en formato json, eligiendo 8601 ya que el 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.


30
2018-04-23 18:35



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

I-JSON significa Internet JSON o Interoperable JSON, según a quién se lo 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 esos datos   los artículos se expresan como valores de cadena en formato ISO 8601, como se especifica   en RFC 3339, con las restricciones adicionales que en mayúsculas   que se usen letras minúsculas, que la zona horaria no se incluya   predeterminado, y que se incluyan segundos finales opcionales incluso cuando   su valor es "00". También se RECOMIENDA que todos los elementos de datos   que contienen duraciones de tiempo se ajustan a la producción de "duración" en   Apéndice A de RFC 3339, con las mismas restricciones adicionales.


19
2018-03-27 18:48



Solo como referencia, he visto este formato utilizado:

Date.UTC(2017,2,22)

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

FWIW: Nunca use segundos desde época en un protocolo de comunicación, ni milisegundos desde época, porque están cargados de peligros gracias a la implementación aleatoria de segundos intercalares (no tiene idea de si el emisor y el receptor implementan correctamente los segundos intercalares UTC).

Es algo que odia a las mascotas, pero muchas personas creen que UTC es solo el nuevo nombre para 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 interminables, realmente está usando UTC. Los segundos intercalares futuros 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 intercalares pero contiene una tabla de referencia desactualizada (más común de lo que cree) y no tiene GMT ni UTC, tiene un sistema wonky 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.


5
2018-02-27 07:33



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

yourDate.substring(0,10)

Esto puede ser útil para ti


1
2017-09-16 11:09



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

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

0
2018-04-10 06:11



Solo hay una respuesta correcta a esto y la mayoría de los sistemas lo malinterpretan. Número de milisegundos desde época, 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 la aplicación o db. ¿Por qué su db se preocupa por qué zona horaria es algo, cuando sabe que va a almacenarlo como un entero de 64 bits y luego realiza los cálculos de transformación?

Elimina los bits extraños y solo trata las fechas como números hasta la IU. Puede usar operadores aritméticos simples para hacer consultas y lógica.


-3
2017-12-16 23:56



es trabajo para mí con el servidor de 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"
            }
}

-3
2017-08-24 06:45



Creo que eso realmente depende del caso de uso. En muchos casos, puede ser más beneficioso usar un modelo de objeto apropiado (en lugar de representar la fecha en una cadena), como sigue:

{
     "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 para humanos también
  • implementa un modelo de objeto 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 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 usted
  • creación fácil con cualquier marco de fecha-hora o implementación en cualquier idioma
  • puede ampliarse 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 lo hace)

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


-11
2018-01-01 15:30