nueva manejo localdatetime horas fechas example ejemplo conociendo java datetime java-8 jodatime java-time

manejo - Diferencias entre Java 8 Date Time API(java.time) y Joda-Time



manejo de horas en java (2)

Características comunes

a) Ambas bibliotecas utilizan tipos inmutables. Joda-Time también ofrece tipos mutables adicionales como MutableDateTime .

b) Además: ambas bibliotecas están inspiradas en el estudio de diseño "TimeAndMoney" de Eric Evans o las ideas de Martin Fowler sobre el estilo de dominio dominado, por lo que se esfuerzan más o menos por un estilo de programación fluido (aunque no siempre perfecto ;-)).

c) Con ambas bibliotecas obtenemos un tipo de fecha de calendario real (llamado LocalDate ), un tipo de hora de pared real (llamado LocalTime ) y la composición (llamada LocalDateTime ). Esa es una gran victoria en comparación con el antiguo java.util.Calendar y java.util.Date .

d) Ambas bibliotecas utilizan un enfoque centrado en el método, lo que significa que alientan al usuario a usar getDayOfYear() lugar de get(DAY_OF_YEAR) . Esto provoca una gran cantidad de métodos adicionales en comparación con java.util.Calendar (aunque este último no es seguro para el tipo debido al uso excesivo de ints).

Actuación

Vea la otra respuesta de @ OO7 que apunta al análisis de Mikhail Vorontsov, aunque el punto 3 (captura de excepciones) es probablemente obsoleto - vea este JDK-bug . El rendimiento diferente (que es en general a favor de JSR-310 ) se debe principalmente al hecho de que la implementación interna de Joda-Time siempre utiliza una primitiva larga similar a tiempo de máquina (en milisegundos).

Nulo

Joda-Time a menudo usa NULL como predeterminado para la zona horaria del sistema, la configuración regional predeterminada, la marca de tiempo actual, etc., mientras que JSR-310 casi siempre rechaza los valores NULL.

Precisión

JSR-310 maneja una precisión de nanosecond mientras que Joda-Time se limita a una precisión de millisecond .

Campos soportados:

Algunas clases en el paquete temporal (por ejemplo, ChronoField y WeekFields ) WeekFields una descripción general de los campos admitidos en Java-8 (JSR-310), mientras que Joda-Time es bastante débil en esta área; consulte DateTimeFieldType . La mayor falta de Joda-Time es la ausencia de campos relacionados con la semana localizados. Una característica común del diseño de implementación de ambos campos es que ambos se basan en valores de tipo long (no hay otros tipos, ni siquiera enumeraciones).

Enumerar

JSR-310 ofrece enums como DayOfWeek o Month mientras que Joda-Time no ofrece esto porque se desarrolló principalmente en los años 2002-2004 antes de Java 5 .

API de zona

a) JSR-310 ofrece más funciones de zona horaria que Joda-Time. Latter no puede proporcionar un acceso programático al historial de transiciones de desplazamiento de zona horaria, mientras que JSR-310 es capaz de hacer esto.

b) Para su información: JSR-310 ha movido su repositorio interno de zona horaria a una nueva ubicación y un formato diferente. La carpeta de la biblioteca antigua lib / zi ya no existe.

Ajustador vs. Propiedad

JSR-310 ha introducido el Interfaz de ajuste TemporalAdjuster como una forma formalizada de externalizar los cálculos y manipulaciones temporales, especialmente para escritores de bibliotecas o marcos. Es una forma agradable y relativamente fácil de integrar nuevas extensiones de JSR-310 (un tipo de equivalente a estático clases de ayuda para el ex java.util.Date ).

Sin embargo, para la mayoría de los usuarios, esta característica tiene un valor muy limitado debido a que la carga para escribir el código aún es del usuario. Las soluciones integradas basadas en el nuevo concepto de TemporalAdjuster no son tantas, en la actualidad solo existe la clase de ayuda TemporalAdjusters con un conjunto limitado de manipulaciones (y las enumeraciones del Month u otros tipos temporales).

Joda-Time ofrece un paquete de campo, pero la práctica ha demostrado que las implementaciones de campo nuevas son muy difíciles de codificar. Por otro lado, Joda-Time ofrece las denominadas propiedades que hacen que algunas manipulaciones sean mucho más fáciles y más elegantes que en JSR-310, por ejemplo, property.withMaximumValue() .

Sistemas de calendario

JSR-310 ofrece 4 sistemas de calendario adicionales. El más interesante es Umalqura (usado en Arabia Saudita). Los otros 3 son: Minguo (Taiwan), japonés (¡solo el calendario moderno desde 1871!) Y ThaiBuddhist (solo correcto después de 1940).

Joda-Time ofrece un calendario islámico basado en la base de cálculo, no un calendario basado en avistamientos como Umalqura. Joda-Time también ofrece el budismo tailandés en una forma similar, Minguo y el japonés no. De lo contrario, Joda-Time también ofrece un calendario copto y etíope (pero sin ningún apoyo para la internacionalización).

Más interesante para los europeos: Joda-Time también ofrece un Gregorian , Julian y gregoriano-juliano mixto. Sin embargo, el valor práctico para los cálculos históricos reales es limitado porque las características importantes, como los comienzos de diferentes años en el historial de fechas, no son compatibles en absoluto (la misma crítica es válida para el antiguo java.util.GregorianCalendar ).

Otros calendarios como el Hebrew o el Persian o el Hindu faltan completamente en ambas bibliotecas.

Dias de la epoca

JSR-310 tiene la clase JulianFields mientras que Joda-Time (versión 2.0) ofrece algunos métodos de ayuda en la clase DateTimeUtils .

Relojes

JSR-310 no tiene interfaz (error de diseño) sino una clase abstracta java.time.Clock que se puede usar para cualquier inyección de dependencia de reloj. Joda-Time ofrece la interfaz MillisProvider y algunos métodos auxiliares en DateTimeUtils en su lugar. De esta manera, Joda-Time también es capaz de soportar modelos controlados por pruebas con diferentes relojes (burla, etc.).

Aritmética de duración

Ambas bibliotecas admiten el cálculo de distancias de tiempo en una o más unidades temporales. Sin embargo, cuando se manejan duraciones de unidad única, el estilo JSR-310 es obviamente mejor (y de larga duración en lugar de usar int):

JSR-310 => long days = ChronoUnit.DAYS.between(date1, date2);

Joda-Time => int days = DAYS.daysBetween(date1, date2).getDays();

El manejo de duraciones de unidades múltiples también es diferente. Incluso los resultados de los cálculos pueden diferir, vea este problema de Joda-Time cerrado. Si bien JSR-310 utiliza un enfoque muy simple y limitado para usar solo las clases Period (duración basada en años, meses y días) y Duration (basada en segundos y nanosegundos), Joda-Time utiliza una forma más sofisticada utilizando la clase PeriodType en para controlar en qué unidades se expresará una duración (Joda-Time, llamada "Período"). Si bien el PeriodType -API es un poco incómodo de usar de una manera similar, JSR-310 no ofrece en absoluto. Especialmente, en JSR-310 aún no es posible definir duraciones mixtas de fecha y hora (por ejemplo, días y horas). Por lo tanto, tenga cuidado si se trata de la migración de una biblioteca a otra. Las bibliotecas en discusión son incompatibles, a pesar de nombres de clase parcialmente iguales.

Intervalos

JSR-310 no admite esta función, mientras que Joda-Time tiene soporte limitado. Véase también esta SO-answer .

Formateo y análisis

La mejor manera de comparar ambas bibliotecas es ver las clases con el mismo nombre DateTimeFormatterBuilder (JSR-310) y DateTimeFormatterBuilder (Joda-Time). La variante JSR-310 es un poco más potente (también puede manejar cualquier tipo de TemporalField siempre que el implementador de campo haya logrado codificar algunos puntos de extensión como resolve() ). La diferencia más importante es sin embargo, en mi opinión:

JSR-310 puede analizar mucho mejor los nombres de las zonas horarias (símbolo de patrón de formato z), mientras que Joda-Time no pudo hacer esto en absoluto en sus versiones anteriores y ahora solo de forma muy limitada.

Otra ventaja de JSR-310 es el soporte para nombres de mes independientes que son importantes en idiomas como el ruso o el polaco, etc. Joda-Time no tiene acceso a dichos recursos , ni siquiera en las plataformas Java-8.

La sintaxis del patrón en JSR-310 también es más flexible que en Joda-Time, permite secciones opcionales (con corchetes), está más orientada hacia el estándar CLDR y ofrece relleno (símbolo de la letra p) y más campos.

De lo contrario, se debe tener en cuenta que Joda-Time puede formatear duraciones utilizando PeriodFormatter . JSR-310 no puede hacer esto.

Espero que esta visión general ayuda. Toda la información recopilada está principalmente allí debido a mis esfuerzos e investigaciones sobre cómo diseñar e implementar una mejor biblioteca de fecha y hora (nada es perfecto).

Actualización del 2015-06-24:

Mientras tanto, he encontrado tiempo para escribir y publicar un resumen tabular para diferentes bibliotecas de tiempo en Java. Las tablas también contienen una comparación entre Joda-Time v2.8.1 y Java-8 (JSR-310). Es más detallado que este post.

Sé que hay preguntas relacionadas con java.util.Date y Joda-Time. Pero después de algunas excavaciones, no pude encontrar un hilo sobre las diferencias entre la API java.time (nueva en Java 8 , definida por JSR 310 ) y Joda-Time .

He oído que la API java.time de Java 8 es mucho más limpia y puede hacer mucho más que Joda-Time. Pero no puedo encontrar ejemplos comparando los dos.

  • ¿Qué puede hacer java.time que Joda-Time no pueda?
  • ¿Qué puede hacer java.time mejor que Joda-Time?
  • ¿Es mejor el rendimiento con java.time?

Java 8 Fecha / Hora:

  1. Java 8 clases se construyen alrededor del tiempo humano. Los hace rápidos para la aritmética / conversión humana.
  2. Los getDayOfMonth componentes de fecha / hora como getDayOfMonth tienen una complejidad O (1) en la implementación de Java 8.
  3. El análisis de OffsetDateTime / OffsetTime / ZonedDateTime es muy lento en Java 8 ea b121 debido a las excepciones lanzadas y capturadas internamente en el JDK.
  4. Un conjunto de paquetes: java.time.* , java.time.chrono.* , java.time.format.* , java.time.temporal.* , java.time.zone.*
  5. Instantes (marcas de tiempo) Fecha y hora Parcial de fecha y hora Parámetros y formateador Zonas horarias Cronologías diferentes (calendarios).
  6. Las clases existentes tienen problemas, como Date no tiene soporte para I18N o L10N. ¡Son mutables!
  7. Más simple y más robusto.
  8. Los relojes pueden ser inyectados.
  9. Los relojes se pueden crear con varias propiedades: relojes estáticos, relojes simulados, relojes de baja precisión (segundos completos, minutos completos, etc.).
  10. Los relojes se pueden crear con zonas horarias específicas. Clock.system(Zone.of("America/Los_Angeles")) .
  11. Hace que la fecha y la hora del manejo del código sean verificables
  12. Hace pruebas independientes de la zona horaria.

Joda-Tiempo:

  1. Joda-Time está utilizando el tiempo de la máquina en el interior. Una implementación manual basada en valores int / long sería mucho más rápida.
  2. Los captadores de Joda-Time requieren el cálculo del tiempo de computadora a humano en cada llamada de captador, lo que hace que Joda-Time se convierta en un cuello de botella en tales escenarios.
  3. Está compuesto por clases inmutables, maneja instantes, fecha y hora, parciales y duraciones. Es flexible. Está bien diseñado.
  4. Representa fechas como instantes. Pero una fecha y hora pueden corresponder a más de un instante. Hora de superposición cuando finaliza el horario de verano. Además de no tener ningún instante que le corresponda en absoluto. Gap hora en que comienza la luz del día. Tiene que realizar cálculos complejos para operaciones simples.
  5. Acepta valores nulos como valores válidos en la mayoría de sus métodos. Conduce a errores sutiles.

Para una comparación más detallada ver: -

Rendimiento de la biblioteca Java 8 Date / Time (así como Joda-Time 2.3 y juCalendar) . & Nueva API de fecha y hora en Java 8