In the Noda Time User’s Guide, the rationale section states:
the public API has been largely rewritten, both to provide an API which is more idiomatic for .NET, and also to rectify some of the Joda Time decisions which the Noda Time team view as “unfortunate”. (Some of these are simply due to having different goals; others I’d argue are really mistakes.)
What are these decisions that are different/better? This would not count differences just for language syntax, but would include anything done to make the users less likely to make a programming error (library usability).
The best place to start is probably the “design philosophy” section of the user guide. But to lay out specific differences between Noda Time and Joda Time:
-
Noda Time keeps much more of its code internal. This makes it less flexible, in that you actually can’t create your own calendar system – but also means the API is simpler both to learn and use.
-
Nullity is almost always an error in Noda Time. No more “if you pass in null for a time zone, we’ll just use the system default.” You need to be explicit.
-
Speaking of defaults… we don’t use the system clock as a default. We’ve got a separate
IClockinterface with aSystemClockimplementation, but nothing defaults to “the current time.” -
Aside from specific builder classes, everything is immutable. I think
MutableDateTime(et al) in Joda Time were a mistake. -
We’ve separated calendar system and time zone from each other, as they’re really very different concerns. So a
LocalDateknows about the calendar system it uses, but not the time zone, for example. -
The manner of resolving local date/time values to zoned date/time values is closer to JSR-310 than Joda Time. We don’t just handle ambiguity/skipped times in some particular manner: we make the user say what they want.
-
Joda Time has various places where it tries to guess what you want from a weakly-typed API (e.g. new
Instant(Object)). Noda Time avoids this as far as it possibly can – it’s much more explicit. -
Noda Time is stricter in what kind of arithmetic you can perform on which types. So for example, you can’t add a
Periodto aZonedDateTime, because there are oddities around daylight saving transitions which could mess things up. Instead, we encourage users to convert toLocalDateTime, do however much arithmetic they want to in a non-zoned context, and then convert back. -
Noda Time uses inheritance rather less – the hierarchies in Joda Time are hugely deep and complicated. The fact that a lot of Noda Time is based on value types actually enforces this anyway, but there are some places where we’re still using class inheritance, but I’ve managed to collapse the inheritance hierarchy significantly… often at the expense of flexibility which I didn’t consider to be worthwhile 🙂
1