Joda-Time: DateTime, DateMidnight y el uso LocalDate

StackOverflow https://stackoverflow.com/questions/2538448

Pregunta

biblioteca Joda-Time incluye diferentes clases de fecha y hora

  

DateTime - reemplazo Inmutable   Calendario de JDK turismo Els href="http://www.joda.org/joda-time/apidocs/org/joda/time/DateMidnight.html" rel="noreferrer"> DateMidnight   - clase inmutable que representa una fecha en que el tiempo se ve obligado a   medianoche turismo Els href="http://www.joda.org/joda-time/apidocs/org/joda/time/LocalDateTime.html" rel="noreferrer"> LocalDateTime -   clase inmutable que representa un local de   fecha y hora (sin zona horaria)

Me pregunto cómo se está utilizando estas clases en su Aplicaciones Capas .

veo ventajas en tener casi todas las interfaces que utilizan LocalDateTime (en la capa de servicios por lo menos) para que mi aplicación no tiene que gestionar zonas horarias y puede asumir con seguridad tiempos siempre en UTC. Mi aplicación podría utilizar DateTime para gestionar zonas horarias en el principio de flujo de la ejecución.

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

¿Fue útil?

Solución

  

veo ventajas en tener casi todos   las Interfaces utilizando LocalDateTime (en   la capa de servicio por lo menos) para que mi   La aplicación no tiene que administrar   Zonas horarias y puede asumir con seguridad tiempos siempre en UTC.

No estoy seguro de entender su línea de pensamiento aquí. LocalDateTime y DateTime representan dos conceptos muy diferentes. No es el caso de que un LocalDateTime tiene otras implícitas zona UTC: en realidad tiene no zona horaria (internamente se puede representar como un DateTime con zona UTC, pero es sólo un detalle de implementación, no importa a el programador que lo utiliza).

Se puede ver en los documentos de la API que, mientras que un DateTime es un " Instant " (un punto en la línea de tiempo del mundo, un concepto físico), un LocalDateTime no es tal cosa. El LocalDateTime es en realidad un Partial , (un " "concepto ciudadano), en una jerarquía de clases diferentes. Los nombres de clases podrían -unfortunately- hacer pensar que LocalDateTime es cierta especialización de DateTime:. Bien, no es

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

Cuando utilizar uno o el otro en la aplicación ... a veces es discutible, pero con frecuencia es lo suficientemente claro, una vez que los conceptos se entienden JodaTime. Y la OMI no tiene mucho que ver con "capas", tal vez más de los casos de uso o escenarios.

Un ejemplo -borderline- no trivial: Usted trabaja en Google, la programación del calendario. Debe dejar al usuario gestionar (añadir, ver, modificar) un evento que incluye una fecha-hora (permite ignorar eventos recurrentes), diga " Tengo una appointement con mi médico de 2019-julio-3 a las 10:00 am ". ¿Cuál es la entidad de fecha-hora para usar en la capa de software (por este caso de uso )? Yo diría: un LocalDateTime. Debido a que el usuario no está realmente tratando con un punto físico en el tiempo, pero con una hora civil: la fecha y hora que muestra el reloj en su muñeca o en su casa. Ni siquiera pensar en zonas horarias (deja pasar por alto el caso especial de un usuario que está viajando por todo el mundo ...) Entonces, en la capa de Negociación de presentación, un LocalDateTime parece la entidad derecha.

Pero supongamos que también debe codificar un escenario diferente: un recordatorio. Cuando el planificador interno de Google detecta que el evento almacenado por el usuario es N minutos en el futuro a partir de ahora, tiene que enviarle un recordatorio. Aquí, " N minutos a partir de ahora " es un concepto totalmente "física" de tiempo, así que aquí la "capa de negocio" se ocupe de unas DateTime. Hay varias alternativas, por ejemplo: el evento se almacena en la base de datos como un LocalDateTime (es decir, justo la hora y fecha sin zona horaria - una frecuencia utiliza un sello de tiempo UTC para representar eso, pero este detalle una implementación.). En este escenario (sólo en este) hay que cargarlo como un DateTime, lo convertimos utilizando un huso horario, probablemente a partir del perfil del usuario.

Otros consejos

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

java.time

momento específico

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

  • Siempre en UTC está representado por Instant .
  • asignado un desplazamiento-de-UTC está representado por OffsetDateTime .
  • Asignar una zona de tiempo completo en lugar de mero desplazamiento se representa por ZonedDateTime .

Estos todos sustituir la clase Instant y DateTime en Joda-Time. Estas clases java.time todos tienen una resolución de nanosegundos frente a los milisegundos utilizados por Joda-Time.

medianoche frente al inicio del día

Para la medianoche, el proyecto Joda-Time concluyó que “la medianoche” es un concepto vago e improductivo. Las clases medias noches y relacionados medianoche fueron desaprobados en versiones posteriores de Joda-Time, sustituido con el concepto práctico de “primer momento del día”.

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

Nunca asuma un día comienza a las 00:00. Anomalías tales como horario de verano (DST) significa el día puede comenzar en otras ocasiones, 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, ver cómo Cuba comienza el día a la 1 de la mañana del resorte DST corte más.

  

zdt: 2017-03-12T01: 00-04: 00 [América / La Habana]

zonificadas

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

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

Si su contexto empresarial implica una zona horaria específica, se puede aplicar para obtener una 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 java.time marco está construido en Java 8 y versiones posteriores. Estas clases suplantar a la problemática de edad legado clases de fecha y hora como java.util.Date , Calendar , y SimpleDateFormat .

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

Para obtener más información, consulte la Oracle Tutorial . Y la búsqueda de desbordamiento de pila durante muchos ejemplos y explicaciones. Especificación es JSR 310 .

¿Dónde obtener las clases java.time?

El ThreeTen-Extra Proyecto extiende java.time con clases adicionales. Este proyecto es un campo de pruebas para posibles futuras adiciones a java.time. Usted puede encontrar algunas clases útiles aquí, como Interval , YearWeek , YearQuarter , y más .

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top