java - instant - localdatetime instance

Joda-Time: uso de DateTime, DateMidnight y LocalDate

Question

Joda-Time biblioteca de Joda-Time incluye diferentes clases de fecha y hora.

DateTime - Reemplazo inmutable para el calendario JDK
DateMidnight - Clase inmutable que representa una fecha en la que el tiempo es forzado a la medianoche
LocalDateTime - Clase inmutable que representa una fecha y hora local (sin zona horaria)

Me pregunto cómo estás usando estas clases en tus aplicaciones en capas .

Veo las ventajas de tener casi todas las Interfaces usando LocalDateTime (al menos en la Capa de Servicios) para que mi Aplicación no tenga que administrar las zonas horarias y pueda asumir las Horas siempre en UTC. Mi aplicación podría usar DateTime para administrar las zonas horarias al comienzo del flujo de ejecución.

También me pregunto en qué escenario puede ser útil DateMidnight.

Answer 1

Veo las ventajas de tener casi todas las Interfaces usando LocalDateTime (al menos en la Capa de Servicios) para que mi Aplicación no tenga que administrar las zonas horarias y pueda asumir las Horas siempre en UTC.

No estoy seguro de entender tu línea de pensamiento aquí. LocalDateTime y DateTime representan dos conceptos muy diferentes. No es el caso de que LocalDateTime tenga una zona horaria UTC implícita: en realidad no tiene zona horaria (internamente puede representarse como una DateTime y hora con la zona horaria UTC, pero es solo un detalle de la implementación, no le importa al programador que la use).

Puede ver en los documentos de la API que, mientras que DateTime es un " Instant " (un punto en la línea de tiempo mundial, un concepto físico), un LocalDateTime NO es tal cosa. LocalDateTime es en realidad un concepto Partial (un concepto "civil") en una jerarquía de clases diferente. Los nombres de las clases podrían, lamentablemente, hacerle pensar que LocalDateTime es una especialización de DateTime : bueno, no lo es.

Un LocalDateTime debe considerarse como un par { Date ( Y/M/D ); Time ( hh:mm:ss.msec )}, un grupo de números que corresponde a la representación estándar "civil" de los datos relacionados con el tiempo. Si nos dan un LocalDateTime , no podemos convertirlo directamente a DateTime , necesitamos especificar una zona horaria; y esa conversión nos lleva a otro tipo de entidad. (Una analogía: cadenas y secuencias de bytes en Java: para convertir entre ellas debe especificar una codificación de conjunto de caracteres, ya que son cosas conceptualmente diferentes)

Cuándo usar uno u otro en la aplicación ... a veces es discutible, pero con frecuencia es lo suficientemente claro, una vez que se entienden los conceptos de Jodatime. Y la OMI no está muy relacionada con las "capas", quizás más con casos o escenarios de uso.

Un ejemplo no trivial de línea de frontera: usted trabaja en Google programando el calendario. Debe permitir que el usuario administre (agregue, vea, modifique) un evento que incluya una fecha y hora (ignoremos los eventos recurrentes), diga " Tengo una cita con mi médico del 2019 al 3 de julio a las 10:00 am ". ¿Cuál es la entidad de fecha y hora para usar en la capa de software (para este caso de uso )? Yo diría: un LocalDateTime . Porque el usuario no está tratando con un punto físico en el tiempo, sino con un tiempo civil: la fecha y hora que muestra el reloj en su muñeca o en su casa. Ni siquiera piensa en las zonas horarias (ignoremos el caso especial de un usuario que está viajando por el mundo ...) Luego, en la capa de negocios y presentación, una LocalDateTime parece la entidad correcta.

Pero suponga que también debe codificar un escenario diferente: un recordatorio. Cuando el programador interno de Google detecte que el evento almacenado por el usuario es de N minutos en el futuro a partir de ahora, debe enviarle un recordatorio. Aquí, " N minutos a partir de ahora " es un concepto totalmente "físico" de tiempo, por lo que aquí la "capa de negocios" trataría con un DateTime . Hay varias alternativas, por ejemplo: el evento se almacenó en la base de datos como LocalDateTime (es decir, solo la hora y la fecha sin la zona horaria - uno usa con frecuencia una marca de tiempo UTC para representar eso, pero esto es un detalle de implementación). En este escenario (solo en este caso) debemos cargarlo como un DateTime , lo convertimos utilizando una zona horaria, probablemente desde el perfil del usuario.

Answer 2

La respuesta de leonbloy es correcta y de vital importancia. Simplemente estoy traduciendo a las clases de java.time que reemplazan el proyecto Joda-Time.

java.time

Momento específico

Para un momento específico en la línea de tiempo:

• Siempre en UTC está representado por Instant .
• El OffsetDateTime representa un desplazamiento de UTC OffsetDateTime .
• Asignar una zona horaria completa en lugar de un simple desplazamiento está representado por ZonedDateTime .

Todos estos reemplazan la clase Instant & DateTime en Joda-Time. Estas clases java.time tienen una resolución de nanoseconds frente a los milisegundos utilizados por Joda-Time.

Medianoche frente al comienzo del día

Para la medianoche, el proyecto Joda-Time concluyó que "medianoche" es un concepto vago e improductivo. Las clases relacionadas con la medianoche y las medianoche fueron desaprobadas en versiones posteriores de Joda-Time, reemplazadas por el concepto práctico de "primer momento del día".

Las clases java.time tomaron la misma lección, utilizando un enfoque de "primer momento del día". Busque los métodos atStartOfDay en las clases LocalDate como LocalDate .

Nunca asuma que un día comienza a las 00:00. Las anomalías como el horario de verano (DST) significan que el día puede comenzar en otros horarios, como 01:00.

ZonedDateTime zdt =
LocalDate.of( 2017 , Month.MARCH , 12 ) // Instantiate a date-only value without time zone.
.atStartOfDay( ZoneId.of( "America/Havana" ) ) ; // Cuba jumps from 00:00 to 01:00 on Spring DST cut-over.

Por ejemplo, vea cómo Cuba comienza el día a la 1 AM en su recorte de primavera DST.

zdt: 2017-03-12T01: 00-04: 00 [America / Havana]

Unzoned

Para representar la vaga idea de momentos posibles en un rango de aproximadamente 26-27 horas pero no un momento real en la línea de tiempo, use LocalDateTime . Esta clase carece a propósito de cualquier desplazamiento desde UTC o zona horaria.

LocalDateTime ldt = LocalDateTime.of( 2017 , Month.JANUARY , 23 , 1 , 2 , 3 , 0 ) ;

Si el contexto de su negocio implica una zona horaria específica, puede aplicarlo para obtener un ZonedDateTime .

ZoneId z = ZoneId.of( "Africa/Tunis" ) ;
ZonedDateTime zdt = ldt.atZone( z ) ; // Determine a specific point on timeline by providing the context of a time zone.

Acerca de java.time

El marco java.time está integrado en Java 8 y posterior. Estas clases suplantan a las problemáticas antiguas clases legacy fecha y hora como java.util.Date , Calendar y SimpleDateFormat .

El proyecto Joda-Time , ahora en modo de mantenimiento , aconseja la migración a las clases java.time .

Para obtener más información, consulte el Tutorial de Oracle . Y busque para obtener muchos ejemplos y explicaciones. La especificación es JSR 310 .

¿Dónde obtener las clases de java.time?

• Java SE 8 , Java SE 9 y posterior
  • Incorporado.
  • Parte de la API Java estándar con una implementación integrada.
  • Java 9 agrega algunas características y correcciones menores.
• Java SE 6 y Java SE 7
  • Gran parte de la funcionalidad de java.time se transfiere a Java 6 y 7 en ThreeTen-Backport .
• Android
  • El proyecto ThreeTenABP adapta ThreeTen-Backport (mencionado anteriormente) específicamente para Android.
  • Consulte Cómo utilizar ThreeTenABP ....

El proyecto ThreeTen-Extra amplía java.time con clases adicionales. Este proyecto es un terreno de prueba para posibles adiciones futuras a java.time. Puede encontrar algunas clases útiles aquí, como Interval , YearWeek , YearQuarter y more .