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 en las ideas de Martin Fowler sobre el estilo controlado por 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 tipo de fecha de calendario real (llamado LocalDate), un tipo de tiempo de pared real (llamado LocalTime) y la composición (llamado LocalDateTime). Esa es una gran victoria en comparación con los viejos java.util.Calendary java.util.Date.
d) Ambas bibliotecas utilizan un enfoque centrado en el método, lo que significa que alientan al usuario a usar en getDayOfYear()lugar de hacerlo 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 de tipo seguro en absoluto debido al uso excesivo de ints).
Actuación
Vea la otra respuesta de @ OO7 señalando el análisis de Mikhail Vorontsov, aunque el punto 3 (captura de excepciones) probablemente sea obsoleto; vea este error JDK . El rendimiento diferente (que es en general favorable a JSR-310 ) se debe principalmente al hecho de que la implementación interna de Joda-Time siempre utiliza una primitiva larga similar a tiempo 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 la precisión de nanosegundos, mientras que Joda-Time se limita a la precisión de milisegundos .
Campos soportados:
Algunas clases en el paquete temporal proporcionan una descripción general de los campos compatibles en Java-8 (JSR-310) (por ejemplo, ChronoField y WeekFields ), mientras que Joda-Time es bastante débil en esta área; consulte DateTimeFieldType . La mayor falta de Joda-Time es aquí la ausencia de campos locales relacionados con la semana. Una característica común de ambos diseños de implementación de campo es que ambos se basan en valores de tipo largo (no hay otros tipos, ni siquiera enumeraciones).
Enum
JSR-310 ofrece enumeraciones como DayOfWeeko Monthmientras 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 hacerlo.
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 biblioteca lib / zi ya no existe.
Ajustador vs. Propiedad
JSR-310 ha introducido la TemporalAdjusterinterfaz como una forma formalizada de externalizar los cálculos y manipulaciones temporales, especialmente para los escritores de bibliotecas o marcos. Esta es una manera agradable y relativamente fácil de incorporar nuevas extensiones de JSR-310 (una especie de equivalente a la ayuda estática clases para ex java.util.Date).
Sin embargo, para la mayoría de los usuarios, esta característica tiene un valor muy limitado porque la carga de escribir código aún recae en el usuario. Las soluciones TemporalAdjusterintegradas basadas en el nuevo concepto no son muchas, actualmente solo existe la clase auxiliar TemporalAdjusterscon un conjunto limitado de manipulaciones (y las enumeraciones Monthu 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, 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 (Taiwán), 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 una base calculadora, no un calendario basado en avistamientos como Umalqura. El budista tailandés 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 un calendario cóptico y etíope (pero sin ningún apoyo para la internacionalización).
Más interesante para los europeos: Joda-Time también ofrece un calendario gregoriano , juliano y mixto gregoriano-juliano. Sin embargo, el valor práctico para los cálculos históricos reales es limitado porque las características importantes como los diferentes años de inicio en el historial de fechas no son compatibles (la misma crítica es válida para los antiguos java.util.GregorianCalendar).
Otros calendarios como el hebreo o el persa o hindú están completamente ausentes en ambas bibliotecas.
Días de la época
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.Clockque puede usarse para cualquier inyección de dependencia de reloj. Joda-Time ofrece la interfaz MillisProvider y algunos métodos auxiliares en DateTimeUtils . De esta forma, Joda-Time también es capaz de admitir modelos probados con diferentes relojes (burlas, 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 una sola unidad, el estilo JSR-310 es obviamente más agradable (y de base larga 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 múltiples unidades de duración también es diferente. Incluso los resultados del cálculo pueden diferir; vea este problema cerrado de Joda-Time . 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(basado en segundos y nanosegundos), Joda-Time usa una forma más sofisticada usando la clase PeriodTypepara controlar en qué unidades se expresará una duración (Joda-Time lo llama "período"). Mientras que laPeriodType-API es de alguna manera incómodo usar una forma similar que JSR-310 no ofrece en absoluto. Especialmente aún no es posible en JSR-310 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 tener parcialmente los mismos nombres de clase.
Intervalos
JSR-310 no es compatible con esta característica, mientras que Joda-Time tiene soporte limitado. Vea también esta respuesta SO .
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 TemporalFieldcondición siempre que el implementador de campo haya logrado codificar algunos puntos de extensión como resolve () ). Sin embargo, la diferencia más importante es, en mi opinión:
JSR-310 puede analizar mucho mejor los nombres de zonas horarias (símbolo de patrón de formato z), mientras que Joda-Time no pudo hacer esto en sus versiones anteriores y ahora solo de una manera muy limitada.
Otra ventaja de JSR-310 es la compatibilidad con nombres de meses independientes que es importante 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 (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 . JSR-310 no puede hacer esto.
Espero que este resumen ayude. 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 el tiempo para escribir y publicar una descripción 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.