Common functions
a) Both libraries use immutable types. Joda-Time also offers other mutable types such as MutableDateTime.
b) Also: Both libraries are inspired by the study of design “TimeAndMoney” by Eric Evans or ideas from Martin Fowler on the style of domination so they strive more or less for one fluent programming style (although not always perfect ;-)).
c) With both libraries we get a real calendar date type (called LocalDate), a type of real wall time (called LocalTime) and dialing (call LocalDateTime). This is a very big win over the old ones Java.util.Calendar And Java.util.Date.
d) Both libraries use a method-centric approach that encourages the user to use getDayOfYear() rather than get(DAY_OF_YEAR). This causes a lot of extra methods than Java.util.Calendar (although the latter is not at all safe for the type due to the excessive use of Ints).
Performance
See the other answer from @ OO7 indicating Mikhail Vorontsov’s analysis even though point 3 (catch exception) is probably out of date – see this JDK-bug . The different performance (which is generally favorable to JSR-310 ) is mainly due to the fact that the internal implementation of Joda-Time always use a primitive as long as the machine (in milliseconds).
Null
Joda-Time often uses NULL as the default for system time zone, locale, current timestamp etc. While JSR-310 almost always rejects NULL values.
precision
Handle JSR-310 nanosecond accuracy while Joda-Time is limited to millisecond precision.
Supported fields:
An overview of the fields supported in Java-8 (JSR-310) is provided by some classes in the time package (e.g. ChronoField And WeekFields ) while Joda-Time is quite weak in this area – see DateTimeFieldType . The biggest shortcoming of Joda-Time here is the absence of localized week-related fields. A common feature of the field implementation design is that both are based on long type values (no other types, not even enumerations).
Enum
Offers JSR-310 enums how DayOfWeek or Month while Joda-Time does not offer this because it was mainly developed in the years 2002-2004 before Java 5 .
Zone API
a) JSR-310 offers more timezone functionality than Joda-Time. Latter is unable to provide programmatic access to the time zone offset transition history while the JSR-310 is able to.
b) For your information: JSR-310 has moved its internal time repository to a new location and to a different format. The old lib / zi library no longer exists.
Adjuster vs. Property
JSR-310 introduced theTemporalAdjuster– interface as a formalized way to externalize calculations and temporal manipulations, especially for libraries or framework writers this is a simple and relatively straightforward way of incorporating new extensions to JSR-310 (a kind of equivalent to static helper classes for ex Java.util.Date).
However, for most users, this feature is of very limited value because the burden of writing code is still with the user. Integrated solutions based on the new TemporalAdjuster– concept are not that many, currently there is only the helper class TemporalAdjusters with a limited set of manipulations (and enumeration Month or other temporal types).
Joda-Time offers a field package, but practice has shown that new field implementations are very difficult to code. On the other hand, Joda-Time offers so-called properties that make some manipulations much easier and more elegant than JSR-310, for example property.withMaximumValue () .
Calendar systems
JSR-310 offers 4 additional calendar systems. The most interesting is Umalqura (used in Saudi Arabia). The other 3 are: Minguo (Taiwan), Japanese (only the modern calendar from 1871!) E ThaiBuddhist (corrected only after 1940).
Joda-Time offers a Islamic calendar calculator based – not a sighting based calendar like Umalqura. The Thai Buddhist is also offered by Joda-Time in a similar form, the Minguo and the Japanese are not. Otherwise, Joda-Time also offers a Coptic and Ethiopian calendar (but without any support for internationalization).
More interesting for Europeans: Joda-Time also offers a Gregorian , Julian and the mixed Gregorian-Julian calendar. However, the practical value for actual historical calculations is limited because important features such as the start of the different year in the date history are not supported (the same criticism is valid for the old Java.util.GregorianCalendar).
Other calendars like Jewish or Persian or Hindu they are completely missing in both libraries.
Era days
JSR-310 has the class JulianFields while Joda-Time (version 2.0) offers some helper methods in the class DateTimeUtils .
Watches
JSR-310 does not have an interface (a design error) but an abstract class Java.time.Clock which can be used for any clock dependence injection. Joda-Time offers the interface MillisProvider and some support methods in DateTimeUtils . In this way, Joda-Time is also able to support tested models with different clocks (derision, etc.).
Arithmetic duration
Both libraries support the calculation of time distances in one or more time units. However, when dealing with single unit durations, the JSR-310 style is obviously nicer (and based on lengths instead of using int):
JSR-310 => long days = ChronoUnit.DAYS.between(date1, date2);
Joda-Time => int days = DAYS.daysBetween(date1, date2).getDays();
The management of the durations of multiple units is also different. Calculation results may also differ – see this closed problem Joda-Time . While JSR-310 uses a very simple and limited approach to use classes only Period (duration based on years, months and days) e Duration (based on seconds and nanoseconds), Joda-Time uses a more sophisticated way using the class PeriodType in to control in which units a duration must be expressed (Joda-Time calls it “Period”). While the API PeriodType– it is somewhat inconvenient to use similarly it is not offered by the JSR-310 at all. Especially in JSR-310 it is not yet possible to define mixed dates and times (based on days and hours, for example). So be warned if it comes to migrating from one library to another. The libraries under discussion are incompatible, despite partially identical class names.
Intervals
JSR-310 does not support this function while Joda-Time has limited support. See this too SO-answer .
Formatting and analysis
The best way to compare both libraries is to view classes with the same name DateTimeFormatterBuilder (JSR-310) and DateTimeFormatterBuilder (Joda-Time). The JSR-310 variant is a bit more powerful (it can also handle any type of TemporalField provided that the implementer of the field was able to code some extension points such as resolve () ). The most important difference however is – in my opinion:
JSR-310 can parse time zone names much better (z symbol pattern format) while Joda-Time is unable to do this at all in its earlier versions and now only in a very limited way.
Another advantage of JSR-310 is the support for standalone month names which is important in languages like Russian or Polish etc. Joda-Time has no access to these resources – not even on Java-8 platforms.
The pattern syntax in JSR-310 is also more flexible than in Joda-Time, allows for optional sections (using square brackets), is more oriented towards the CLDR standard, and offers padding (letter symbol p) and more fields.
Otherwise it should be noted that Joda-Time can format durations using PeriodFormatter . JSR-310 cannot do this.
Hope this overview helps. All the information gathered is mainly there thanks to my efforts and research on how to design and implement a better data-and-time library (nothing is perfect).
Update 2015-06-24:
In the meantime I have found time to write and publish a tabular overview for the different time libraries in Java. The tables also contain a comparison between Joda-Time v2.8.1 and Java-8 (JSR-310). It is more detailed than this post.