Noda Time vs Joda Time?

Nella Guida dell'utente di Noda Time , la sezione logica afferma:

l'API pubblica è stata ampiamente riscritta, sia per fornire un'API più idiomatica per .NET, sia per correggere alcune delle decisioni di Joda Time che il team di Noda Time considera "sfortunate". (Alcuni di questi sono semplicemente dovuti ad obiettivi diversi; altri direi che sono davvero degli errori.)

Quali sono queste decisioni diverse / migliori? Ciò non conta le differenze solo per la sintassi del linguaggio, ma include qualsiasi cosa fatta per rendere gli utenti meno propensi a commettere un errore di programmazione (usabilità della libreria).

Il miglior punto di partenza è probabilmente la sezione "filosofia del design" della guida per l'utente. Ma per stabilire differenze specifiche tra Noda Time e Joda Time:

• Noda Time mantiene molto più del suo codice interno. Ciò lo rende meno flessibile, in quanto in realtà non è possibile creare il proprio sistema di calendario - ma significa anche che l'API è più semplice da imparare e da usare.

• La nullità è quasi sempre un errore in Noda Time. Non più "se si passa a null per un fuso orario, utilizzeremo semplicemente l'impostazione predefinita di sistema". Devi essere esplicito.

• Parlando di default ... non usiamo l'orologio di sistema come predefinito. Abbiamo IClockun'interfaccia separata con SystemClockun'implementazione, ma per impostazione predefinita nulla è "l'ora corrente".

• A parte specifiche classi di costruttori, tutto è immutabile. Penso che MutableDateTime(et al) in Joda Time siano stati un errore.

• Abbiamo separato il sistema di calendario e il fuso orario l'uno dall'altro, poiché sono preoccupazioni molto diverse. Quindi è a LocalDateconoscenza del sistema di calendario che utilizza, ma non del fuso orario, ad esempio.

• Il modo di risolvere i valori di data / ora locali in valori di data / ora suddivisi in zone è più vicino a JSR-310 di Joda Time. Non gestiamo solo ambiguità / tempi saltati in un modo particolare: facciamo dire all'utente ciò che vogliono.

• Joda Time ha vari luoghi in cui cerca di indovinare ciò che desideri da un'API di tipo debole (ad es. Nuovo Instant(Object)). Noda Time lo evita il più possibile - è molto più esplicito.

• Noda Time è più rigoroso in quale tipo di aritmetica è possibile eseguire su quali tipi. Quindi, ad esempio, non puoi aggiungere a Perioda ZonedDateTime, perché ci sono delle stranezze nelle transizioni dell'ora legale che potrebbero rovinare le cose. Invece, incoraggiamo gli utenti a convertirsi LocalDateTime, fare comunque tutta l'aritmetica che vogliono in un contesto non suddiviso in zone e quindi riconvertire.

• Noda Time usa l'eredità piuttosto meno: le gerarchie in Joda Time sono estremamente profonde e complicate. Il fatto che molto tempo di Noda sia basato su tipi di valore lo impone comunque, ma ci sono alcuni posti in cui stiamo ancora usando l'eredità di classe, ma sono riuscito a far crollare la gerarchia dell'eredità in modo significativo ... spesso a spese di flessibilità che non ho ritenuto utile :)