Noda Time vs Joda Time?

Im Noda Time User's Guide heißt es im Abschnitt Begründung:

Die öffentliche API wurde weitgehend überarbeitet, um eine für .NET idiomatischere API bereitzustellen und um einige der Entscheidungen von Joda Time zu korrigieren, die das Noda Time-Team als "unglücklich" ansieht. (Einige davon sind einfach darauf zurückzuführen, dass sie unterschiedliche Ziele verfolgen; andere, von denen ich behaupten würde, sind wirklich Fehler.)

Was sind diese Entscheidungen, die anders / besser sind? Dies würde Unterschiede nicht nur für die Sprachsyntax zählen, sondern alles einschließen, was getan wird, um die Wahrscheinlichkeit eines Programmierfehlers für die Benutzer zu verringern (Verwendbarkeit der Bibliothek).

Der beste Ausgangspunkt ist wahrscheinlich der Abschnitt "Designphilosophie" in der Bedienungsanleitung. Aber um spezifische Unterschiede zwischen Noda Time und Joda Time herauszustellen :

• Noda Time behält viel mehr von seinem Code intern bei. Dies macht es weniger flexibel, da Sie tatsächlich kein eigenes Kalendersystem erstellen können - aber es bedeutet auch, dass die API einfacher zu erlernen und zu verwenden ist.

• In der Noda-Zeit ist die Nichtigkeit fast immer ein Fehler. Nicht mehr "Wenn Sie für eine Zeitzone null übergeben, verwenden wir nur die Standardeinstellung des Systems." Sie müssen explizit sein.

• Apropos Standardeinstellungen ... Wir verwenden die Systemuhr nicht als Standardeinstellung. Wir haben eine separate IClockSchnittstelle mit einer SystemClockImplementierung, aber nichts ist standardmäßig auf "die aktuelle Zeit" eingestellt.

• Abgesehen von bestimmten Builder-Klassen ist alles unveränderlich. Ich denke MutableDateTime(et al) in der Joda-Zeit waren ein Fehler.

• Wir haben Kalendersystem und Zeitzone voneinander getrennt, da es sich um sehr unterschiedliche Anliegen handelt. So LocalDatekennt a beispielsweise das verwendete Kalendersystem, nicht aber die Zeitzone.

• Die Art und Weise, wie lokale Datums- / Uhrzeitwerte in zonierte Datums- / Uhrzeitwerte aufgelöst werden, ist näher an JSR-310 als an Joda Time. Wir behandeln Mehrdeutigkeiten / übersprungene Zeiten nicht nur auf eine bestimmte Art und Weise: Wir lassen den Benutzer sagen, was er will.

• Joda Time hat verschiedene Stellen, an denen versucht wird, zu erraten, was Sie von einer schwach typisierten API erwarten (z Instant(Object). B. neu ). Noda Time vermeidet dies so weit wie möglich - es ist viel expliziter.

• Die Noda-Zeit ist strenger, wenn es darum geht, welche Art von Arithmetik Sie für welche Typen ausführen können. So können Sie zum Beispiel kein a Periodzu a hinzufügen ZonedDateTime, da es bei Übergängen zwischen Sommer- und Winterzeit Merkwürdigkeiten gibt, die die Dinge durcheinander bringen könnten. Stattdessen empfehlen wir Benutzern, in zu konvertieren LocalDateTime, in einem nicht in Zonen aufgeteilten Kontext zu rechnen und dann zurück zu konvertieren.

• Noda Time verwendet weniger Vererbung - die Hierarchien in Joda Time sind enorm tief und kompliziert. Die Tatsache, dass viel Noda-Zeit auf Werttypen basiert, erzwingt dies sowieso, aber es gibt einige Stellen, an denen wir immer noch die Klassenvererbung verwenden, aber ich habe es geschafft, die Vererbungshierarchie erheblich zu reduzieren ... oft auf Kosten von flexibilität die ich nicht für lohnenswert hielt :)