There are some fairly high-profile database systems out there that do
not store any timezone information in timestamp columns.  It's not
required by the SQL standard.  The Calendar passed to get/setDate is
used to determine the timezone of the stored date, not the timezone of
the app or the timezone of the DB server's system clock, for cases
where all dates are stored using some fixed timezone that may not
correspond to the app's default timezone.

For example, you may have mandated that DB dates are always in UTC, in
which case if you want to store 2008-01-01 07:00:00 -0500 in the
database you would pass in a Date representing that time and a
calendar whose timezone was UTC, and allow the driver to adjust
appropriately.  The driver or the DB would be required to store
2008-01-01 12:00:00 as its (timezoneless) timestamp.

If you omit the Calendar option, the Date passed will be stored in the
current default timezone (and the example above would store 2008-01-01
07:00:00 instead).

-o

Recall the ancient roots of SQL.  I goes back at least to the 70s.
This was back in the days when servers ran on local time and all
terminals displayed server time.

The database then did not concern itself with timezones.  It just used
local time.

It sounds like this is a kludge to avoid any translation of the
timestamp.

If we were designing this today, the database would store all
timestamps in UTC, and when you were preparing a display,  the
user-timezone would automatically be used to adjust all dates.

As part of login, you would get the timezone, language, encoding etc
the user prefers, perhaps part of the login database.