Libraries – Noda Time vs Joda Time: A Comprehensive Comparison

joda-timelibrariestime

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).

Best Answer

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 IClock interface with a SystemClock implementation, 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 LocalDate knows 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 Period to a ZonedDateTime, because there are oddities around daylight saving transitions which could mess things up. Instead, we encourage users to convert to LocalDateTime, 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 :)

Related Solutions

Unit-testing – How to automatically test a time check

One simple way is to pass in the time from outside the method:

doSomething(long currentTime) {
   //...stuff
   startTime = currentTime;
   //... more stuff
}

Your production code that calls the method can pass in the real value for System.currentTimeMillis(), whereas your unit test(s) can pass in a specific known value.

Of course, this isn't quite the same as your original. Another possibility that is a little more complex but should mimic the behaviour of your of your original more closely:

doSomething(ITimeGetter timeGetter) {
   //...stuff
   startTime = timeGetter.GetCurrentTime;
   //... more stuff
}

Define the interface:

interface ITimeGetter
{
   long GetCurrentTime();
}

Two implementations, one for the production code:

class RealTimeGetter implements ITimeGetter
{
  long GetCurrentTime()
  {
      return System.currentTimeMillis();
  }
}

One for the unit tests:

class TimeGetterForTests implements ITimeGetter
{
  long GetCurrentTime()
  {
     // return a known value.
  }
}

Instantiate an ITimeGetter appropriate to your scenario and pass it in to the method you want to test.

Time Calculation by Computers – How It Works

I think it's safe to assume there is a similar "starting date" in other languages so I guess the specific implementation in Java doesn't matter.

Pretty much all computers use this or a similar variation of Unix time.

How is the time calculation performed by the computer? How does it know exactly how many milliseconds have passed from that given "starting date and time" to the current date and time?

Typically, a computer includes one or more hardware devices that count time, usually based on a crystal oscillator (the same as used in most modern clocks). There are serveral variations/standards for such devices:

These timer devices usually have a separate battery that allows them to continue running when the computer is switched off. The computer interacts with them in two ways:

When it boots up, it reads the current time from the device
At regular intervals, the device causes a hardware interrupt that is handled by the OS to do any time-dependant tasks.

However, the crystal oscillators used in the hardware timers have limited precision and over time drift away from the correct time. For applications where it's important to have an accurate clock (or just to avoid the hassle of having to manually adjust it), computers regularly synchronize their time via the Network Time Protocol with a time server, which is connected (directly or indirectly) to a high-precision atomic clock.

Best Answer

Related Solutions

Unit-testing – How to automatically test a time check

Time Calculation by Computers – How It Works

Related Topic