Problema de zona horaria en la aplicación web

Quiero conocer las mejores prácticas para lidiar con la zona horaria en la aplicación web. Tomemos un ejemplo, el servidor está en la zona horaria UTC, user1 y user2 están en una zona horaria diferente. ¿Cuál es una forma adecuada de lidiar con la fecha?

  1. Cuando user1 agrega una nueva fecha, está en una zona horaria diferente y el Servidor está en UTC, ¿debo convertir la fecha a UTC y almacenar en la base de datos?

  2. Al mostrar la fecha de obtención de la fecha que está en formato UTC y luego convertirla según la zona horaria del cliente y mostrarla. ¿Es la forma correcta?

  3. ¿Qué es el problema DST? ¿Es efecto este proceso?

  4. En algún lugar donde leí esa fecha de la tienda en milisegundos, ¿es buena idea? Ahora mismo almaceno como fecha / hora.

  5. ¿Hay algún método adecuado o biblioteca para hacer esto por favor sugiera

Mi problema es

el cliente con GMT +5: 30 crea un registro y establece la fecha y la hora de entrega, digamos 30 de junio de 2014 a las 11:30 p.m. GMT +5: 30

Así que Transporter con GMT -3: 00 puede ver una hora local exacta en GMT -3: 00 que el cliente selecciona. ¿Cómo lograr esto?

1

Sí. Generalmente, la mejor práctica es almacenar todos sus valores de fecha y hora en UTC. Su lógica de negocio debería funcionar en UTC .

Es posible que también desee almacenar el valor ingresado por el usuario o la fuente de datos externa como una pista de auditoría o ayuda de depuración. Pero use UTC para el registro oficial.

Sí, la zona horaria del servidor debe configurarse en UTC (o, si no es posible, usar Reykjavík Islandia). Pero no dependas de esto en tu progtwigción. Especifique su zona horaria deseada en su código en lugar de depender de los valores predeterminados.

2

Sí. Convertir a una hora localizada para la presentación. A menos que, por supuesto, el usuario prefiera UTC.

Piense en ello como parte de la localización. Cuando se internacionaliza, trabaja con valores clave en su código. Luego, en la presentación, utiliza el valor clave para buscar una cadena de traducción localizada para mostrarla al usuario.

3

Sin problema. Si por “DST” quiere decir el horario de verano, el uso de una biblioteca de fecha y hora decente manejará automáticamente los ajustes para el DST. Advertencia: debe mantener actualizada la lista de definiciones de zonas horarias que utiliza su biblioteca, ya que los gobiernos cambian las reglas con frecuencia.

Si el ajuste para DST (o zonas horarias) causa confusión o desinformación con sus usuarios, entonces debe mostrar UTC en ese caso.

4

No. No almacene ni trabaje con milisegundos en la mayoría de los casos. Las bases de datos y las bibliotecas de fecha y hora pueden hacerlo internamente, pero usted no debería hacerlo.

Algunos tipos nerds sugerirán el seguimiento de milisegundos. Pero trabajar con la fecha y la hora como milisegundos es como trabajar con el texto como matrices de bytes. Usamos bibliotecas de código con niveles más altos de abstracción para manejar todas las complejidades del texto (UTF-8, normalización Unicode de diacríticos, etc.) y agregar métodos útiles (buscar, reemplazar, etc.). Así es con la fecha y la hora.

Además, el uso de milisegundos causará confusión y dificultará la depuración, ya que no puede entender su valor fácilmente. El trabajo de fecha y hora es intrínsecamente complicado y propenso a errores. Usar milisegundos no ayuda.

Y no todas las bases de datos y otras bibliotecas usan milisegundos internamente. Algunos utilizan segundos completos, o microsegundos, o nanosegundos. Tampoco todos usan la misma época .

5

En Java tenemos dos buenas bibliotecas de fecha y hora: Joda-Time y java.time (Java 8).

El paquete java.time se inspiró en Joda-Time pero se vuelve a diseñar. Comparten conceptos similares, pero no son idénticos. Puede usar ambos en su código siempre que tenga cuidado con sus declaraciones de import . Ambos tienen sus propias fortalezas y debilidades.

Evita juDate / .Calendar

No utilice las clases java.util.Date y .Calendar empaquetadas con Java. Son notoriamente problemáticos, con fallas tanto en el diseño como en la implementación. Han sido suplantados por Sun / Oracle con el nuevo paquete java.time.

Tanto Joda-Time como java.time incluyen métodos prácticos para traducir a / desde un objeto java.util.Date para cuando alguna otra clase requiera un objeto juDate.

Consejos de bonificación

Respecto a los formatos de texto:

  • Evita el formato de cadena que usaste en tu pregunta. Es difícil de manejar y difícil de analizar.
  • Aprenda sobre el uso de varios formatos de cadena definidos por el estándar ISO 8601 para representaciones textuales de valores de fecha y hora.
  • No deje caer el cero inicial en las compensaciones, como lo hizo en su pregunta. Eso romperá el código en las bibliotecas y viola los requisitos de los estándares. Siempre escribe +05:30 , nunca +5:30 . Haz que sea un hábito incluso cuando escribas prosa, no solo en tu código de progtwigción.

Código de ejemplo

Código de ejemplo con Joda-Time 2.3.

Cree una instancia de la fecha y hora, local a un desplazamiento de +05: 30. Elegí arbitrariamente la zona horaria de Calcuta. Usted reemplazaría con uno apropiado, por supuesto.

 DateTimeZone timeZoneKolkata = DateTimeZone.forID( "Asia/Kolkata" ); DateTime dateTimeKolkata = new DateTime( 2014, DateTimeConstants.JUNE, 30, 23, 30, 0, timeZoneKolkata ); 

Ajuste el mismo momento a otra zona horaria con un desplazamiento de -03: 00. Elegí arbitrariamente América / Buenos_Aires.

 DateTimeZone timeZoneBuenos_Aires = DateTimeZone.forID( "America/Buenos_Aires" ); DateTime dateTimeBuenos_Aires = dateTimeKolkata.withZone( timeZoneBuenos_Aires ); 

Convertir a UTC.

 DateTime dateTimeUtc = dateTimeKolkata.withZone( DateTimeZone.UTC );