A DESCRIPTION OF THE REQUEST :
Problems with the current java.util.Date

1- because of it's mutability, we usually need to make defensive copies to have robust code, to use dates as keys of maps, to share the dates by multiple threads, etc.

2- java.util.Date actually represents a time and therefore it is sensitive to timezones.
This is fine when you want to store something that is time-related, for example the date/times of an event in a log.  On the other hand, this is a problem when you store just a date, such as a birthdate.  Suppose you are in Europe, you store the birthdate serialized in a file.  Then, somebody else in America reads the file and deserializes the date : surprise !  The date is sometimes not the same, because you had to specify explicitly a common timezone.  This is a common source of bugs.

3- Many companies and smart developers have developed their own immutable date.  However, this is a non standard solution and creates therefore integration problems with libraries, tools, etc.
A date is a fundamental basic value type.  An immutable simple true date in the standard jdk would solve all the problems.

JUSTIFICATION :
We need to be able to store (and share) a simple date such as birthdate, that will always be this same date under any circumnstance.
I mean with a true date-only semantics and not  the date part of a time like java.util.Date.


CUSTOMER SUBMITTED WORKAROUND :
Of course, there are many workarounds, but they are all heavy and error-prone.
In most applications, bugs appear as soon clients in new timezones are added.
###@###.### 10/11/04 08:53 GMT