localdatetime - offsetdatetime java

¿Cuál es la diferencia entre java 8 ZonedDateTime y OffsetDateTime?

Question

He leído la documentación, pero todavía no puedo saber cuándo debo usar uno u otro:

• OffsetDateTime
• ZonedDateTime

De acuerdo con la documentación, OffsetDateTime debe usarse al escribir la fecha en la base de datos, pero no entiendo por qué.

Answer 1

P: ¿Cuál es la diferencia entre java 8 ZonedDateTime y OffsetDateTime?

Los javadocs dicen esto:

" OffsetDateTime , ZonedDateTime e Instant almacenan un instante en la línea de tiempo con una precisión de nanosegundos. Instant es el más simple, simplemente representa el instante. OffsetDateTime agrega al instante el desplazamiento desde UTC / Greenwich, que permite que la fecha y hora local sea obtenido. ZonedDateTime agrega ZonedDateTime completas de zona horaria ".

Fuente: OffsetDateTime

Por lo tanto, la diferencia entre OffsetDateTime y ZonedDateTime es que este último incluye las reglas que cubren los ajustes del horario de verano y otras anomalías.

Dicho simplemente:

Zona horaria = ( Offset-From-UTC + Rules-For-Anomalies)

P: De acuerdo con la documentación, OffsetDateTime debe usarse al escribir la fecha en la base de datos, pero no entiendo por qué.

Las fechas con desfases de hora local siempre representan los mismos instantes en el tiempo y, por lo tanto, tienen un orden estable. Por el contrario, el significado de las fechas con información de zona horaria completa es inestable ante los ajustes a las reglas para las zonas horarias respectivas. (Y esto sucede; por ejemplo, para valores de fecha y hora en el futuro). Entonces, si almacena y luego recupera un ZonedDateTime la implementación tiene un problema:

• Puede almacenar el desplazamiento calculado ... y el objeto recuperado puede tener un desplazamiento que es inconsistente con las reglas actuales para el id de zona.

• Puede descartar el desplazamiento calculado ... y el objeto recuperado representa un punto diferente en la línea de tiempo absoluta / universal que el que estaba almacenado.

Si usa la serialización de objetos Java, la implementación de Java 9 toma el primer enfoque. Esta es posiblemente la forma "más correcta" de manejar esto, pero esto no parece estar documentado. (Los controladores JDBC y los enlaces ORM presumiblemente están tomando decisiones similares, y con suerte lo están haciendo bien).

Pero si está escribiendo una aplicación que almacena manualmente valores de fecha / hora, o que se basa en java.sql.DateTime , entonces lidiar con las complicaciones de un id de zona es ... probablemente algo que debe evitarse. De ahí el consejo.

Tenga en cuenta que las fechas cuyo significado / orden es inestable en el tiempo pueden ser problemáticas para una aplicación. Y dado que los cambios en las reglas de zona son un caso marginal, los problemas pueden surgir en momentos inesperados.

Una (posible) segunda razón para el consejo es que la construcción de un ZonedDateTime es ambigua en ciertos puntos. Por ejemplo, en el período en el que está "retrasando los relojes", combinar una hora local y un id de zona puede proporcionarle dos desplazamientos diferentes. ZonedDateTime elegirá constantemente uno sobre el otro ... pero esta no siempre es la opción correcta.

Ahora, esto podría ser un problema para cualquier aplicación que construya valores ZonedDateTime esa manera. Pero desde la perspectiva de alguien que ZonedDateTime una aplicación empresarial es un problema mayor cuando los valores (posiblemente incorrectos) de ZonedDateTime son persistentes y se usan más tarde.