Время Нода против Время Йода?

В Руководстве пользователя Noda Time в разделе обоснования говорится:

публичный API был в значительной степени переписан, чтобы обеспечить API, более идиоматичный для .NET, а также исправить некоторые решения Joda Time, которые команда Noda Time считает «неудачными». (Некоторые из них просто из-за разных целей; другие я бы поспорил, это действительно ошибки.)

Каковы эти решения, которые отличаются / лучше? Это не учитывало бы различия только для синтаксиса языка, но включало бы в себя все, что делало бы, чтобы пользователи с меньшей вероятностью допустили ошибку программирования (удобство использования библиотеки).

Лучше всего начать с раздела «философия дизайна» в руководстве пользователя. Но чтобы выделить конкретные различия между Noda Time и Joda Time:

• Noda Time хранит гораздо больше внутреннего кода. Это делает его менее гибким, поскольку вы фактически не можете создать свою собственную календарную систему, но также означает, что API проще как в изучении, так и в использовании.

• Нуль-ноль - почти всегда ошибка в Noda Time. Больше не нужно "если вы введете нулевое значение для часового пояса, мы просто используем системное значение по умолчанию". Вы должны быть явными.

• Говоря о настройках по умолчанию ... мы не используем системные часы по умолчанию. У нас есть отдельный IClockинтерфейс с SystemClockреализацией, но нет значения по умолчанию «текущего времени».

• Помимо определенных классов строителей, все является неизменным. Я думаю MutableDateTime(и другие) в Joda Time были ошибкой.

• Мы разделили календарную систему и часовой пояс друг от друга, потому что это действительно очень разные проблемы. Таким образом, он LocalDateзнает о календарной системе, которую он использует, но не о часовом поясе, например.

• Способ преобразования локальных значений даты / времени в зонированные значения даты / времени ближе к JSR-310, чем к Joda Time. Мы не просто обрабатываем неопределенность / пропущенные времена каким-то особым образом: мы заставляем пользователя говорить то, что он хочет.

• У Joda Time есть различные места, где он пытается угадать, что вы хотите от слабо типизированного API (например, нового Instant(Object)). Noda Time избегает этого настолько, насколько это возможно, - это гораздо более явно.

• Время Нода более строго в том, какую арифметику вы можете выполнять на каких типах. Так, например, вы не можете добавить a Periodк a ZonedDateTime, потому что существуют переходы при переходе на летнее время, которые могут испортить ситуацию. Вместо этого мы призываем пользователей выполнить преобразование LocalDateTime, выполнить сколько угодно арифметических действий в не зональном контексте и затем выполнить обратное преобразование.

• Noda Time использует наследование гораздо реже - иерархия в Joda Time чрезвычайно глубока и сложна. Тот факт, что большая часть времени Noda основана на типах значений, на самом деле обеспечивает это, но в некоторых местах мы все еще используем наследование классов, но мне удалось значительно разрушить иерархию наследования ... часто за счет гибкости, которую я не считал стоящей :)