Diferencias entre Java 8 Date Time API (java.tiempo) y Joda-Tiempo

Question

Diferencias entre Java 8 Date Time API (java.tiempo) y Joda-Tiempo

Sé que hay preguntas relacionadas con java.útil.Fecha y Joda-Hora. Pero después de algunas investigaciones, no pude encontrar un hilo sobre las diferencias entre el java.time API (nuevo en Java 8, definido por JSR 310) y Joda-Time.

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

Lo que puede java.el tiempo hace que Joda-El tiempo no puede?
Lo que puede java.tiempo hacer mejor que Joda-Tiempo?
Es el mejor rendimiento con java.tiempo?

226

java datetime java-8 jodatime java-time

Author: JodaStephen, 2014-07-08

Source

2 answers

Java 8 Fecha / Hora:

Las clases Java 8 se construyen alrededor del tiempo humano. Los hace rápidos para la aritmética/conversión de datetime humanos.
Los captadores de componentes de fecha/hora como getDayOfMonth tienen complejidad O(1) en la implementación de Java 8.
Análisis de OffsetDateTime/OffsetTime/ZonedDateTime es muy lento en Java 8 ea b121 debido a excepciones lanzadas y atrapadas internamente en el JDK.
Un conjunto de paquetes: java.time.*, java.time.chrono.*, java.time.format.*, java.time.temporal.*, java.time.zone.*
Instantes (marcas de tiempo) Fecha y Hora Parser Parcial de Fecha y Hora y Formateador Zonas horarias Diferentes cronologías (calendarios).
Las clases existentes tienen problemas como Date no tiene soporte para I18N o L10N. ¡Son mutables!
Más simple y más robusto.
Los relojes se pueden inyectar.
Los relojes se pueden crear con varias propiedades: relojes estáticos, relojes burlados, relojes de baja precisión (segundos enteros, minutos enteros, etc.).
Los relojes se pueden crear con zonas horarias específicas. Clock.system(Zone.of("America/Los_Angeles")).
Hace que la fecha y hora de manejo de código sea comprobable.
Hace que las pruebas sean independientes de la zona horaria.

Joda-Tiempo:

Joda-Time está usando machine time inside. Una implementación manual basada en valores int / long sería mucho más rápida.
Los getters Joda-Time requieren el cálculo del tiempo de computadora a humano en cada llamada getter, lo que hace que Joda-Time sea un cuello de botella en tales escenarios.
Se compone de clases inmutables que maneja Instantes, Fecha y Hora, Parciales y Duraciones Es flexible Está bien diseñado.
Representa las fechas como instantes. Pero una fecha y hora puede corresponder a más de un instante. Hora de solapamiento cuando termina el horario de verano. Así como no tener ningún instante que le corresponda en absoluto. Hora sabática cuando empieza la luz del día. Tiene que realizar cálculos complejos para operaciones simples.
Acepta valores nulos como valores válidos en la mayoría de sus métodos. Conduce a errores sutiles.

Para comparación más detallada ver :-

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

38

Author: OO7,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-07-10 20:20:58

score 358 · Accepted Answer

Características Comunes

A) Ambas bibliotecas usan 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 ideas de Martin Fowler sobre el estilo impulsado por el dominio 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 calendario real tipo de fecha (llamado LocalDate), un tipo de tiempo de pared real (llamado LocalTime) y la composición (llamada LocalDateTime). Esa es una victoria muy grande en comparación con los viejos java.util.Calendar y java.util.Date.

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

Rendimiento

Ver la otra respuesta de @OO7 apuntando a el análisis de Mikhail Vorontsov aunque el punto 3 (captura de excepciones) es probablemente obsoleto-ver 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 usa una máquina-tiempo-como larga-primitiva (en milisegundos).

Null

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 JSR - 310 casi siempre rechaza valores NULOS.

Precisión

JSR-310 maneja precisión de nanosegundos mientras que Joda-Time está limitado a precisión de milisegundos.

Campos soportados:

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

Enum

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.

Zona API

A) JSR-310 ofrece más funciones de zona horaria que Joda-Time. Este último no es capaz de proporcionar un acceso programático al historial de transiciones de offset de zona horaria, mientras que JSR-310 es capaz de hacer esto.

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

Ajustador vs. Propiedad

JSR-310 ha introducido el TemporalAdjuster-interfaz como una forma formalizada de externalizar cálculos temporales y manipulaciones, especialmente para la biblioteca o framework-writers esta es una forma agradable y relativamente fácil de incrustar nuevas extensiones de JSR-310 (una especie de equivalente a las clases de ayuda estática para anteriores java.util.Date).

Para la mayoría de los usuarios, sin embargo, esta característica tiene un valor muy limitado porque la carga de escribir código sigue siendo del usuario. Las soluciones integradas basadas en el nuevo concepto TemporalAdjuster no son tantas, actualmente solo hay la clase helper TemporalAdjusters con un conjunto limitado de manipulaciones (y los enums Month u otros tipos temporales).

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

Sistemas de Calendario

JSR-310 ofrece 4 sistemas de calendario extra. El más interesante es Umalqura (usado en Arabia Saudita). Los otros 3 son: Minguo (Taiwán), japonés (¡solo el calendario moderno desde 1871!) and ThaiBuddhist (only correct after 1940).

Joda-Time ofrece un calendario islámico basado en la base de cálculo - no un calendario basado en avistamientos como Umalqura. El tailandés-budista también es ofrecido por Joda-Time en una forma similar, Minguo y el japonés no. De lo contrario Joda-Time también ofrece 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 Gregoriano, Juliano y calendario mixto gregoriano-juliano. Sin embargo, el valor práctico para los cálculos históricos reales es limitado porque características importantes como diferentes comienzos de año en el historial de fechas no son compatibles en absoluto (la misma crítica es válida para java.util.GregorianCalendar antiguos).

Otros calendarios como hebreo o persa o Hindú están completamente ausentes en ambas bibliotecas.

Epoch days

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

Relojes

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

Duración aritmética

Ambas bibliotecas soportan el cálculo de distancias temporales en una o más unidades temporales. Sin embargo, al manejar duraciones de una sola unidad, el estilo JSR-310 es obviamente más agradable (y basado en largo en lugar de usar int):

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

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

El manejo de duraciones de unidades múltiples también es diferente. Incluso los resultados del cálculo pueden diferir-ver este cerrado Joda-Time issue . Mientras que JSR-310 usa 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 usa una forma más sofisticada usando la clase PeriodType para controlar en qué unidades se expresará una duración (Joda-Time lo llaman "Período"). Mientras que la PeriodType-API es de alguna manera incómoda de usar una forma similar no es ofrecida por JSR-310 en absoluto. Especialmente en JSR-310 todavía no es posible definir duraciones mixtas de fecha y hora (basadas en días y horas, por ejemplo). Así que tenga cuidado si se trata de la migración de una biblioteca a otra. Las bibliotecas en discusión son incompatibles-a pesar de los nombres de clase parcialmente iguales.

Intervalos

JSR-310 no apoye esta característica 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 iguales 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 (formato símbolo de patrón z), mientras que Joda-Time no podía hacer esto en absoluto en sus versiones anteriores y ahora solo de una manera muy limitada.

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

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

De lo contrario, debe tenerse en cuenta que Joda-Time puede formatear duraciones usando PeriodFormatter. El JSR-310 no puede hacer esto.

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

Actualización desde 2015-06-24:

Mientras tanto he encontrado el 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.