Solución:
Recomiendo usar fechas ISO 8601. Especialmente este formato
2014-03-12T13:37:27+00:00
es portátil en muchos lenguajes de programación.
Editar:
JSON solo conoce estos tipos:
string
number
object
array
true
false
null
Las fechas y las fechas y horas se almacenan mejor como cadenas en un formato que se utilice ampliamente.
Por supuesto, debería guardar String en un JSON. Pero digamos que desea filtrar las fechas. Aún puede almacenar un “número” como una cadena como “125” (decimal codificado en binario) y será útil cuando lo vuelva a convertir a 125. Dicho esto, si desea personalizar su número de fecha para filtrar, por ejemplo: Use tipo largo y realizar bit a bit operaciones en él. https://docs.oracle.com/javase/tutorial/java/nutsandbolts/op3.html
- Reserve 12 bits para YYYY hasta el año 4096-1.
- Reserve 4 bits para MM porque (0-11) es suficiente.
- Reserve 5 bits para DD porque el día del mes es (1-31).
Puede seguir reservando bits durante horas, minutos hasta 64 bits. En este caso, DD / MM / AAAA es de 21 bits. Al utilizar este enfoque, acepta @Clay Ferguson y puede filtrar un conjunto de claves en un mapa en términos de “<" y ">” por año, mes, día muy fácil y probablemente muy rápido.
Supongo que la mejor respuesta depende del contexto en el que se usará esa fecha / hora.
TL / DR;
el formato correcto depende de …
- el contexto de cómo se utilizarán los datos (consulte los ejemplos a continuación)
- si las personas o el código están consumiendo el json y si su lenguaje de programación o biblioteca admite fácilmente formatos específicos.
Sugiero usar números json (marcas de tiempo de Unix) y luego combinarlos con zonas horarias de usuario o una única “zona horaria de procesamiento” (cadena json) almacenada por separado, según el caso de uso. Esto permite que se presente al usuario la representación de fecha / hora más relevante y le permite usar fácilmente diferentes formatos de fecha / hora según la ubicación / configuración regional del usuario.
Alternativamente, si la legibilidad json para humanos es importante para usted, puede usar el formato de cadena ISO, pero aún hacer el análisis y las conversiones de zona horaria en el código para obtener la máxima flexibilidad en la representación de fechas / horas fáciles de usar.
Advertencia Si está escribiendo estas marcas de tiempo a mano, no las estropee. Las compensaciones para diferentes zonas horarias cambian en diferentes fechas en diferentes regiones a lo largo del año y si coloca la compensación incorrecta para una región / fecha determinada, entonces su marca de tiempo no representará el momento correcto en el tiempo … y cuando lo analice y formatee es probable que tenga problemas con la visualización de la hora incorrecta.
Si desea que la fecha JSON sea fácilmente legible por humanos
es decir, si desea que un ser humano lea el json directamente y que la fecha / hora tenga un significado.
En este caso, la respuesta de @Ribtoks es probablemente la mejor. Aunque si la fecha / hora se almacena en una zona horaria diferente a la del usuario, el usuario puede estar confundido y / o necesitar hacer conversiones de zona horaria en su cabeza para interpretar correctamente la fecha / hora.
Mayor tentación por la edición manual por parte de humanos y errores de formato que conducirán a errores de análisis. Además, las compensaciones de UTC incorrectas (compensación / hora incorrectas para una región / fecha determinada) darán como resultado que se muestren fechas / horas incorrectas a los usuarios después del formateo.
Si el json es solo almacenamiento de datos y la fecha / hora se representará por código
Formato de fecha / hora local del usuario
es decir, desea mostrar un momento específico en el tiempo (fecha / hora) a un usuario en su zona horaria local.
En este caso, además de los datos de fecha / hora que representan el momento específico, necesita una forma de identificar cuál es la zona horaria “correcta” para un usuario determinado (tema diferente).
Su código deberá analizar / convertir los datos de fecha / hora JSON para que pueda combinarse con los datos de la zona horaria del usuario (p. Ej. America/Denver o Europe/Berlin) para imprimir formato de forma sencilla. Echa un vistazo a moment-timezone biblioteca para esto.
Por ejemplo, el momento en el tiempo:
December 31, 2020 8:00 PM America/Denver
es lo mismo que
January 1, 2021 4:00 AM Europe/Berlin
Este tipo de comportamiento a menudo es deseable con cosas como las redes sociales o publicaciones de blogs o foros de mensajes donde un usuario quiere saber cuándo se publicó algo en su propia hora local y no le importa la zona horaria del autor.
En este caso, dado que tengo que analizar / formatear la fecha / hora, generalmente almaceno la fecha / hora en la marca de tiempo de Unix (número entero … json).
Tomar un número y hacer cálculos matemáticos es computacionalmente más simple que analizar una marca de tiempo de cadena que incluye la zona horaria incorporada para comprender el momento específico subyacente en el tiempo para luego formatear una nueva cadena de fecha / hora para un usuario en una zona horaria diferente .
Evento / Ubicación-Formato de fecha / hora local
es decir, desea mostrar un momento específico en el tiempo (fecha / hora) a un usuario en una zona horaria específica.
Ejemplo: fecha / hora de un concierto de música (en persona) en Berlín. Si tiene asistentes a un concierto que compran entradas en Londres, sería confuso mostrarles a qué hora comienza el concierto en Londres, ya que asistirán al evento en Berlín.
Este es el mismo caso que el caso “Local de usuario” anterior con la diferencia de que en lugar de formatear / representar el momento específico en diferentes zonas horarias para cada usuario, representaría la fecha / hora en una única zona horaria específica de ubicación del evento. “.
Entonces, además de almacenar la fecha / hora específica, también debe almacenar la zona horaria en la que desea representar esa fecha / hora.
Si bien podría preformatear la fecha / hora como una cadena, esto le brinda menos opciones para cambiar programáticamente (es decir, con código) el formato de fecha. Por ejemplo, es posible que desee utilizar la zona horaria local del evento, pero utilizar diferentes formatos de fecha / hora para los usuarios de diferentes países.
por ejemplo, para un concierto a las 7PM el 25 de noviembre de 2020 en Berlín. Mismo momento en el tiempo, misma zona horaria, pero diferentes formatos.
Estados Unidos
11/25/20 7:00PM Europe/Berlin
Alemania
25.11.20 19:00 Europe/Berlin
Reino Unido
25/11/20 19:00 Europe/Berlin
Entonces, en este caso, también almacenaría la fecha / hora como un número json (marca de tiempo de Unix) y luego también almacenaría la zona horaria del evento como una cadena junto con esa marca de tiempo. Esto en contra simplifica el cálculo del análisis sintáctico / conversión de zona horaria. Luego, aún debe averiguar la preferencia de formato de fecha / hora específica de un usuario (configuración regional del navegador, perfil de usuario, etc., fuera del alcance de esta pregunta).
Anécdota acerca de equivocarse en la zona horaria / compensaciones
Tenía un colega que tenía la zona horaria incorrecta (lo que resultó en una compensación UTC incorrecta para su ubicación) configurada en su computadora.
Para solucionar este problema, desactivó la hora de la red y ajustó manualmente el reloj de su computadora para corregir la zona horaria incorrecta.
Cuando enviaba invitaciones a reuniones para una hora específica, las invitaciones incluyen una hora y la zona horaria de esa hora … lo cual es importante, por supuesto, cuando tiene una llamada que cruza los límites de la zona horaria para que todos vean la reunión en su hora local y marquen. -en al mismo tiempo. En el caso de mis colegas, por supuesto, estas reuniones se enviaron para una zona horaria diferente.
Estaba bastante malhumorado porque todos faltaban a sus reuniones por una hora y nos mostró cómo lo había programado para las 3 p.m. pero todos recibimos una invitación para las 4 p.m.
La moral de la historia … los trucos generalmente finalmente son contraproducentes, por lo que es muy importante asegurarse de haber almacenado el momento correcto / previsto en el tiempo. Siempre puede cambiar la zona horaria / formato en el que se muestra ese momento específico en el tiempo más tarde, pero solo si ha almacenado el momento correcto para empezar.
Obtener el momento subyacente en el tiempo correctamente entra en juego principalmente cuando se trata de la entrada de formularios (por ejemplo, el selector de fecha que da YYYY-MM-DD y el selector de tiempo que da HH: MM). Debe asegurarse de que estas cadenas de entrada de fecha / hora de un usuario se interpreten con un contexto de zona horaria según el caso de uso.