N+?? The time library in your programming language is correct.
Every time library I've ever dealt with will have serious problems with at least one issue listed on the original article or in the comments here. JodaTime (on the JVM) is by far the best, but even they have problems, and are creating a new library to solve those.
I think that for the vast majority of real-world software applications JodaTime is bloated and unnecessary.
Most applications need only three 'classes' to represent time:
1. A timestamp (ie. number of milliseconds since midnight on 1 January 1970 GMT)
2. A Gregorian Date (ie. three numbers representing day, month, year)
3. A TimeZone (to convert between 1 and 2)
In Java the first and third types are perfectly represented by java.util.Date and java.util.TimeZone. The second class can be represented by something like this:
http://calendardate.sourceforge.net/
Hmm...I did not know that! I should really have said 'eg.' instead of 'ie.'
The point of the above 'timestamp' is is to represent a specific instant in time, independent of any time zone or calendar system. You can use Unix time for this purpose.
Every time library I've ever dealt with will have serious problems with at least one issue listed on the original article or in the comments here. JodaTime (on the JVM) is by far the best, but even they have problems, and are creating a new library to solve those.