Noda Time vs Joda Time?

En la Guía del usuario de Noda Time , la sección de justificación establece:

la API pública se ha reescrito en gran medida, tanto para proporcionar una API que es más idiomática para .NET, como para rectificar algunas de las decisiones de Joda Time que el equipo de Noda Time considera "desafortunadas". (Algunos de estos se deben simplemente a tener objetivos diferentes; otros diría que son realmente errores).

¿Cuáles son estas decisiones que son diferentes / mejores? Esto no contaría las diferencias solo para la sintaxis del lenguaje, sino que incluiría cualquier cosa que se haga para que los usuarios tengan menos probabilidades de cometer un error de programación (usabilidad de la biblioteca).

El mejor lugar para comenzar es probablemente la sección de "filosofía de diseño" de la guía del usuario. Pero para establecer diferencias específicas entre Noda Time y Joda Time:

• Noda Time mantiene mucho más de su código interno. Esto lo hace menos flexible, ya que en realidad no puede crear su propio sistema de calendario, pero también significa que la API es más simple de aprender y usar.

• La nulidad es casi siempre un error en Noda Time. No más "si pasa nulo para una zona horaria, solo usaremos el valor predeterminado del sistema". Necesitas ser explícito.

• Hablando de valores predeterminados ... no usamos el reloj del sistema como predeterminado. Tenemos una IClockinterfaz separada con una SystemClockimplementación, pero nada predeterminado es "la hora actual".

• Aparte de las clases específicas de constructor, todo es inmutable. Creo que MutableDateTime(et al) en Joda Time fueron un error.

• Hemos separado el sistema de calendario y la zona horaria entre sí, ya que en realidad son preocupaciones muy diferentes. Entonces, LocalDateconoce el sistema de calendario que usa, pero no la zona horaria, por ejemplo.

• La manera de resolver los valores locales de fecha / hora en valores de fecha / hora zonificados está más cerca de JSR-310 que Joda Time. No solo manejamos la ambigüedad / tiempos omitidos de una manera particular: hacemos que el usuario diga lo que quiera.

• Joda Time tiene varios lugares donde intenta adivinar lo que quiere de una API débilmente tipada (por ejemplo, nueva Instant(Object)). Noda Time evita esto en la medida de lo posible, es mucho más explícito.

• Noda Time es más estricto en qué tipo de aritmética puede realizar en qué tipos. Entonces, por ejemplo, no puede agregar un Perioda a ZonedDateTime, porque hay rarezas alrededor de las transiciones de horario de verano que podrían estropear las cosas. En su lugar, alentamos a los usuarios a realizar la conversión LocalDateTime, realizar la aritmética que deseen en un contexto no dividido en zonas y luego volver a convertir.

• Noda Time usa la herencia bastante menos: las jerarquías en Joda Time son muy profundas y complicadas. El hecho de que una gran cantidad de Noda Time se base en tipos de valor realmente lo hace cumplir de todos modos, pero hay algunos lugares donde todavía estamos usando la herencia de clases, pero he logrado colapsar la jerarquía de herencia significativamente ... a menudo a expensas de flexibilidad que no consideraba que valiera la pena :)