Joda Time vs Noda Time?

No Guia do usuário do Noda Time , a seção de justificativa declara:

a API pública foi amplamente reescrita, tanto para fornecer uma API mais idiomática para o .NET quanto para corrigir algumas das decisões do Joda Time que a equipe do Noda Time vê como "infelizes". (Alguns destes são simplesmente devido a objetivos diferentes; outros eu argumentaria que são realmente erros.)

Quais são essas decisões que são diferentes / melhores? Isso não contaria diferenças apenas para a sintaxe da linguagem, mas incluiria qualquer coisa feita para diminuir a probabilidade de os usuários cometerem um erro de programação (usabilidade da biblioteca).

O melhor lugar para começar é provavelmente a seção "filosofia de design" do guia do usuário. Mas, para estabelecer diferenças específicas entre o tempo de Noda e o tempo de Joda:

• O Noda Time mantém muito mais do seu código interno. Isso o torna menos flexível, pois você realmente não pode criar seu próprio sistema de calendário - mas também significa que a API é mais simples de aprender e usar.

• A nulidade quase sempre é um erro no tempo de Noda. Chega de "se você passar nulo por um fuso horário, usaremos o padrão do sistema". Você precisa ser explícito.

• Falando em padrões ... não usamos o relógio do sistema como padrão. Temos uma IClockinterface separada com uma SystemClockimplementação, mas nada como "o horário atual".

• Além de classes específicas do construtor, tudo é imutável. Eu acho que MutableDateTime(et al) em Joda Time foram um erro.

• Separamos o sistema de calendário e o fuso horário, pois são preocupações muito diferentes. Portanto, você LocalDatesabe sobre o sistema de calendário usado, mas não o fuso horário, por exemplo.

• A maneira de resolver valores de data / hora locais para valores de data / hora zoneadas é mais próxima do JSR-310 do que do Joda Time. Não lidamos apenas com ambiguidades / tempos ignorados de alguma maneira específica: fazemos o usuário dizer o que deseja.

• O Joda Time tem vários locais onde ele tenta adivinhar o que você quer de uma API de tipo fraco (por exemplo, nova Instant(Object)). O Noda Time evita isso na medida do possível - é muito mais explícito.

• O Noda Time é mais rígido em que tipo de aritmética você pode executar em quais tipos. Assim, por exemplo, você não pode adicionar um Perioda a ZonedDateTime, porque há esquisitices em torno das transições de horário de verão que podem atrapalhar as coisas. Em vez disso, incentivamos os usuários a se converterem LocalDateTime, fazerem a aritmética que quiserem em um contexto não zonado e, em seguida, converter novamente.

• Noda Time usa herança um pouco menos - as hierarquias no Joda Time são imensas e complicadas. O fato de grande parte do tempo Noda ser baseado em tipos de valor realmente o impõe, mas em alguns lugares ainda estamos usando a herança de classe, mas eu consegui reduzir a hierarquia de herança significativamente ... muitas vezes às custas de flexibilidade que eu não considerava valer a pena :)