[Darryl]: Methods in Date been mostly deprecated. There is very little you are encouraged to do with it other than compare two Dates or display the Date in the default format. I disagree. Just because many of the original methods and constructors were ill-conceived does not mean that the remaining constructors and methods should not be used. For example the DateFormat class (and SimpleDateFormat) certainly use Dates when parsing and formatting. A Date is a simple, small object, very convenient for simply representing a date/time. The only thing smaller and simpler is a long (the one you'd get from Date.getTime()).
But using Date instead has a very important benefit - it automatically documents that the data here represents a date/time. If you pass a long around, there's more chance that another programmer will see the data without understanding its significance (the fact that it represents milliseconds since 000 GMT, Jan 1, 1970) unless you spend extra effort documenting this. By using Date, that becomes obvious. All the documentation you need is already present in the class.
I agree with Joel's statements about Calendars. For many applications they're needlessly complex, and contain many possible sources of error for programmers. (E.g. day of month starts with 1, but month starts with 0.) I avoid using Calendar except when the nature of the problem requires it. I find at least 3/4 of the time, Date and DateFormat (or SimpleDateFormat) are all I need.
If you find you need to do a lot of date/time calculations, I recommend the
Joda Time library. It's much less painful to use than Calendar.