JSR 310, which supplanted the old date-time classes with java.time in Java 8, justifies itself in the original JSR as follows:
2.5 What need of the Java community will be addressed by the proposed
specification?
Currently Java SE has two separate
date and time APIs - java.util.Date
and java.util.Calendar. Both APIs are
consistently described as difficult to
use by Java developers on weblogs and
forums. Notably, both use a zero-index
for months, which is a cause of many
bugs. Calendar has also suffered from
many bugs and performance issues over
the years, primarily due to storing
its state in two different ways
internally.
One classic bug (4639407) prevented
certain dates from being created in a
Calendar object. A sequence of code
could be written that could create a
date in some years but not in others,
having the effect of preventing some
users from entering their correct
birth dates. This was caused by the
Calendar class only allowing a
daylight savings time gain of one hour
in summer, when historically it was
plus 2 hours around the time of the
second world war. While this bug is
now fixed, if at some point in the
future a country chose to introduce a
daylight savings time gain of plus
three hours in summer, then the
Calendar class would again be broken.
The current Java SE API also suffers
in multi-threaded environments.
Immutable classes are known to be
inherently thread-safe as their state
cannot change. However, both Date and
Calendar are mutable, which requires
programmers to consider cloning and
threading explicitly. In addition, the
lack of thread-safety in
DateTimeFormat is not widely known,
and has been the cause of many hard to
track down threading issues.
As well as the problems with the
classes that Java SE has for datetime,
it has no classes for modelling other
concepts. Non-time-zone dates or
times, durations, periods and
intervals have no class representation
in Java SE. As a result, developers
frequently use an int to represent a
duration of time, with javadoc
specifying the unit.
The lack of a comprehensive date and
time model also results in many common
operations being trickier than they
should be. For example, calculating
the number of days between two dates
is a particularly hard problem at
present.
This JSR will tackle the problem of a
complete date and time model,
including dates and times (with and
without time zones), durations and
time periods, intervals, formatting
and parsing.
