Características comuns
a) Ambas as bibliotecas usam tipos imutáveis. O Joda-Time também oferece tipos mutáveis adicionais, como MutableDateTime.
b) Além disso: Ambas as bibliotecas são inspiradas no estudo de design "TimeAndMoney" de Eric Evans ou em idéias de Martin Fowler sobre estilo orientado a domínio, para que se esforcem mais ou menos por um estilo de programação fluente (embora nem sempre seja perfeito ;-)).
c) Nas duas bibliotecas, obtemos um tipo de data do calendário real (chamado LocalDate), um tipo de hora da parede real (chamado LocalTime) e a composição (chamada LocalDateTime). Essa é uma vitória muito grande em comparação com as antigas java.util.Calendare java.util.Date.
d) Ambas as bibliotecas usam uma abordagem centrada no método, o que significa que incentivam o usuário a usar em getDayOfYear()vez de get(DAY_OF_YEAR). Isso causa muitos métodos extras em comparação com java.util.Calendar(embora este último não seja totalmente seguro para o tipo devido ao uso excessivo de ints).
atuação
Veja a outra resposta de @ OO7 apontando para a análise de Mikhail Vorontsov, embora o ponto 3 (captura de exceção) seja provavelmente obsoleto - veja este bug do JDK . O desempenho diferente (que é geralmente a favor do JSR-310 ) deve-se principalmente ao fato de a implementação interna do Joda-Time sempre usar um primitivo longo do tipo máquina-tempo (em milissegundos).
Nulo
O Joda-Time geralmente usa NULL como padrão para o fuso horário do sistema, localidade padrão, carimbo de data / hora atual etc. enquanto o JSR-310 quase sempre rejeita valores NULL.
Precisão
O JSR-310 lida com precisão de nanossegundos, enquanto o Joda-Time é limitado à precisão de milissegundos .
Campos suportados:
Uma visão geral sobre os campos suportados no Java-8 (JSR-310) é fornecida por algumas classes no pacote temporal (por exemplo, ChronoField e WeekFields ), enquanto o Joda-Time é bastante fraco nessa área - consulte DateTimeFieldType . A maior falta de Joda-Time é aqui a ausência de campos relacionados à semana localizados. Um recurso comum do design de implementação de campo é que ambos são baseados em valores do tipo long (nenhum outro tipo, nem mesmo enumerações).
Enum
O JSR-310 oferece enums como DayOfWeekou Monthenquanto o Joda-Time não oferece isso porque foi desenvolvido principalmente nos anos 2002-2004 antes do Java 5 .
API da zona
a) O JSR-310 oferece mais recursos de fuso horário do que o Joda-Time. O Latter não pode fornecer um acesso programático ao histórico de transições de deslocamento de fuso horário, enquanto o JSR-310 é capaz de fazer isso.
b) Para sua informação: JSR-310 mudou seu repositório de fuso horário interno para um novo local e um formato diferente. A pasta da biblioteca antiga lib / zi não existe mais.
Ajustador vs. Propriedade
O JSR-310 introduziu a TemporalAdjusterinterface como uma maneira formalizada de externalizar cálculos e manipulações temporais, especialmente para escritores de bibliotecas ou estruturas. Essa é uma maneira fácil e agradável de incorporar novas extensões do JSR-310 (uma espécie equivalente ao auxiliar estático aulas para ex java.util.Date).
Para a maioria dos usuários, no entanto, esse recurso tem um valor muito limitado, porque o ônus de escrever código ainda é do usuário. As soluções integradas baseadas no novo TemporalAdjusterconceito não são tantas; atualmente, existe apenas a classe auxiliar TemporalAdjusterscom um conjunto limitado de manipulações (e as enumerações Monthou outros tipos temporais).
O Joda-Time oferece um pacote de campo, mas a prática mostrou evidências de que novas implementações de campo são muito difíceis de codificar. Por outro lado, o Joda-Time oferece as chamadas propriedades que tornam algumas manipulações muito mais fáceis e mais elegantes do que no JSR-310, por exemplo, property.withMaximumValue () .
Sistemas de calendário
O JSR-310 oferece 4 sistemas de calendário extras. O mais interessante é o Umalqura (usado na Arábia Saudita). Os outros três são: Minguo (Taiwan), japonês (apenas o calendário moderno desde 1871!) E ThaiBuddhist (correto somente após 1940).
O Joda-Time oferece um calendário islâmico baseado na base de cálculo - não um calendário baseado em avistamento como Umalqura. O tailandês-budista também é oferecido pela Joda-Time de forma semelhante, o Minguo e o japonês não. Caso contrário, o Joda-Time também oferece calendário copta e etiópico (mas sem qualquer apoio à internacionalização).
Mais interessante para os europeus: o Joda-Time também oferece um calendário gregoriano , juliano e misto-gregoriano-juliano. No entanto, o valor prático para cálculos históricos reais é limitado porque recursos importantes como diferentes anos iniciados no histórico de datas não são suportados (a mesma crítica é válida para os antigos java.util.GregorianCalendar).
Outros calendários como hebraica ou persa ou Hindu são completamente ausente nas duas bibliotecas.
Dias da época
O JSR-310 possui a classe JulianFields, enquanto o Joda-Time (versão 2.0) oferece alguns métodos auxiliares na classe DateTimeUtils .
Relógios
O JSR-310 não possui interface (um erro de design), mas uma classe abstrata java.time.Clockque pode ser usada para qualquer injeção de dependência de clock. O Joda-Time oferece a interface MillisProvider e alguns métodos auxiliares no DateTimeUtils . Dessa forma, o Joda-Time também é capaz de suportar modelos orientados a testes com relógios diferentes (zombando etc.).
Duração aritmética
Ambas as bibliotecas suportam o cálculo de distâncias no tempo em uma ou mais unidades temporais. No entanto, ao lidar com durações de unidade única, o estilo JSR-310 é obviamente melhor (e de longa duração em vez de usar int):
JSR-310 => long days = ChronoUnit.DAYS.between(date1, date2);
Tempo de Joda => int days = DAYS.daysBetween(date1, date2).getDays();
O manuseio de durações de várias unidades também é diferente. Até os resultados dos cálculos podem diferir - veja este problema fechado do Joda-Time . Enquanto o JSR-310 usa uma abordagem muito simples e limitada para usar apenas as classes Period(duração com base em anos, meses e dias) e Duration(com base em segundos e nanossegundos), o Joda-Time usa uma maneira mais sofisticada de usar a classe PeriodTypepara controlar em que unidades deve ser expressa uma duração (Joda-Time denominada "Período"). Enquanto oPeriodType-API é, de alguma forma, complicado de usar de uma maneira semelhante, não é oferecido pelo JSR-310. Especialmente ainda não é possível no JSR-310 definir durações mistas de data e hora (com base em dias e horas, por exemplo). Portanto, esteja avisado se se trata de migração de uma biblioteca para outra. As bibliotecas em discussão são incompatíveis - apesar dos nomes das mesmas classes parcialmente.
Intervalos
O JSR-310 não suporta esse recurso enquanto o Joda-Time possui suporte limitado. Veja também esta resposta SO .
Formatação e análise
A melhor maneira de comparar as duas bibliotecas é exibir as classes de mesmo nome DateTimeFormatterBuilder (JSR-310) e DateTimeFormatterBuilder (Joda-Time). A variante JSR-310 é um pouco mais poderosa (também pode lidar com qualquer tipo de TemporalFieldcondição, desde que o implementador de campo tenha conseguido codificar alguns pontos de extensão, como resolve () ). Diferença mais importante é no entanto - na minha opinião:
O JSR-310 pode analisar muito melhor os nomes de fuso horário (símbolo de padrão de formato z), enquanto o Joda-Time não conseguiu fazer isso nas versões anteriores e agora apenas de uma maneira muito limitada.
Outra vantagem do JSR-310 é o suporte a nomes de meses independentes, importantes em idiomas como russo ou polonês etc. O Joda-Time não tem acesso a esses recursos - nem mesmo nas plataformas Java-8.
A sintaxe do padrão no JSR-310 também é mais flexível do que no Joda-Time, permite seções opcionais (usando colchetes), é mais orientada ao padrão CLDR e oferece preenchimento (símbolo da letra p) e mais campos.
Caso contrário, deve-se notar que o Joda-Time pode formatar durações usando PeriodFormatter . O JSR-310 não pode fazer isso.
Espero que esta visão geral ajude. Todas as informações coletadas estão lá principalmente devido aos meus esforços e investigações sobre como projetar e implementar uma melhor biblioteca de data e hora (nada é perfeito).
Atualização de 24/06/2015:
Enquanto isso, encontrei tempo para escrever e publicar uma visão geral tabular para diferentes bibliotecas de tempo em Java. As tabelas também contêm uma comparação entre o Joda-Time v2.8.1 e o Java-8 (JSR-310). É mais detalhado que este post.