Czas Noda vs Czas Joda?

W podręczniku użytkownika Noda Time sekcja uzasadnienia stanowi:

publiczny interfejs API został w dużej mierze przepisany, zarówno w celu zapewnienia interfejsu API, który jest bardziej idiomatyczny dla platformy .NET, jak i w celu skorygowania niektórych decyzji Joda Time, które zespół Noda Time uważa za „niefortunne”. (Niektóre z nich wynikają po prostu z różnych celów; inni twierdzę, że to naprawdę błędy).

Jakie są te decyzje, które są inne / lepsze? Nie liczyłoby to różnic tylko ze względu na składnię języka, ale obejmowałoby wszystko, aby użytkownicy nie popełnili błędu programistycznego (użyteczność biblioteki).

Najlepszym miejscem na rozpoczęcie jest prawdopodobnie sekcja „filozofia projektowania” w podręczniku użytkownika. Ale aby przedstawić konkretne różnice między czasem Noda a czasem Joda:

• Noda Time zachowuje znacznie więcej kodu wewnętrznego. To sprawia, że ​​jest mniej elastyczny, ponieważ nie możesz stworzyć własnego systemu kalendarza - ale oznacza również, że interfejs API jest łatwiejszy zarówno do nauki, jak i do używania.

• Nieważność jest prawie zawsze błędem w Czasie Nody. Nigdy więcej „jeśli podasz wartość zerową dla strefy czasowej, użyjemy tylko domyślnego systemu”. Musisz być wyraźny.

• Mówiąc o domyślnych ... nie używamy zegara systemowego jako domyślnego. Mamy osobny IClockinterfejs z SystemClockimplementacją, ale nic nie domyślnie „bieżąca godzina”.

• Oprócz konkretnych klas konstruktorów wszystko jest niezmienne. Myślę, że MutableDateTime(i wsp.) W Joda Time byli pomyłką.

• Oddzieliliśmy od siebie system kalendarza i strefę czasową, ponieważ są to naprawdę bardzo różne obawy. Więc LocalDatewie o używanym systemie kalendarza, ale nie na przykład o strefie czasowej.

• Sposób rozpoznawania lokalnych wartości daty / godziny na strefowe wartości daty / godziny jest bliższy JSR-310 niż czas Joda. Nie traktujemy tylko niejednoznaczności / pomijanych czasów w określony sposób: sprawiamy, że użytkownik mówi, co chce.

• Joda Time ma różne miejsca, w których próbuje odgadnąć, czego chcesz od słabo napisanego API (np. Nowego Instant(Object)). Noda Time unika tego na tyle, na ile to możliwe - jest to o wiele bardziej wyraźne.

• Czas Nody jest bardziej rygorystyczny w tym, jaką arytmetykę możesz wykonać na jakich typach. Na przykład nie można dodać znaku a Perioddo ZonedDateTime, ponieważ istnieją dziwne przejścia wokół zmian czasu letniego, które mogłyby popsuć sytuację. Zamiast tego zachęcamy użytkowników do konwersji LocalDateTime, wykonywania dowolnej arytmetyki w kontekście niestrefowym, a następnie do ponownej konwersji.

• Czas Noda wykorzystuje mniej dziedziczenia - hierarchie w Czasie Jody są niezwykle głębokie i skomplikowane. Fakt, że wiele Noda Time opiera się na typach wartości, faktycznie to wymusza, ale są pewne miejsca, w których wciąż używamy dziedziczenia klas, ale udało mi się znacznie zwinąć hierarchię dziedziczenia ... często kosztem elastyczności, której nie uważałem za wartościową :)