java.sql.Timestamp
A thin wrapper around java.util.Date
that allows the JDBC API to identify this as an SQL TIMESTAMP value.
If you check java.sql.Timestamp
JavaDoc, it is very explicit that this class extends from java.util.Date
(as java.sql.Date
does). And in real world projects you must plain java.util.Date
when storing the data in your database and mostly java.sql.Timestamp
since it stores date and time value, while java.sql.Date
just stores date value.
On the other hand, java.util.Calendar
is abstract since there are more implementations of this apart from java.util.GregorianCalendar
. If you see the code of Calendar#getInstance
from HotSpot, you will see that it calls createCalendar(TimeZone.getDefaultRef(), Locale.getDefault(Locale.Category.FORMAT))
, and this method code uses 3 different calendars: BuddhistCalendar
, JapaneseImperialCalendar
and GregorianCalendar
. This code is copied from JDK 7 source:
private static Calendar createCalendar(TimeZone zone,
Locale aLocale) {
Calendar cal = null;
String caltype = aLocale.getUnicodeLocaleType("ca");
if (caltype == null) {
// Calendar type is not specified.
// If the specified locale is a Thai locale,
// returns a BuddhistCalendar instance.
if ("th".equals(aLocale.getLanguage())
&& ("TH".equals(aLocale.getCountry()))) {
cal = new BuddhistCalendar(zone, aLocale);
} else {
cal = new GregorianCalendar(zone, aLocale);
}
} else if (caltype.equals("japanese")) {
cal = new JapaneseImperialCalendar(zone, aLocale);
} else if (caltype.equals("buddhist")) {
cal = new BuddhistCalendar(zone, aLocale);
} else {
// Unsupported calendar type.
// Use Gregorian calendar as a fallback.
cal = new GregorianCalendar(zone, aLocale);
}
return cal;
}
Now, why to work directly with Calendar
instead of GregorianCalendar
? Because you must work with abstract classes and interfaces when provided instead of working directly with implementations. This is better explained here: What does it mean to “program to an interface”?
Apart from this, if you will work with date and times, I recommend using a library like Joda-Time that already handles and solves lot of the problems with the current Java Date API and also provides methods to retrieve this date and times object in java.util.Date
flavor.