Timestamp changes committed to HEAD

I've committed my Timestamp/Date/Time changes to CVS HEAD; here's the
commit message. With these changes {get,set}{Timestamp,Date,Time} should
respect Calendars properly and not make any assumptions about server
timezone vs. JVM timezone.

Assuming this works as people expect (please test!), any thoughts on
whether this is suitable to backport to 8.0? It *is* a big set of
changes, but the stable driver is pretty broken in this area as it stands.

-O


Timestamp/Time/Date work per discussion on pgsql-jdbc.

Rewrote quite a bit of TimestampUtils so that timezones are correctly
handled both when parsing and when stringizing values.

TimestampUtils is now an instance attached to the Connection so we can
have different behaviour for 7.3 vs. 7.4 (7.3 does not allow timezone
specifications in time literals).

Added TimezoneTest to test all the various legal conversions when
Calendars are involved.

Server versions and what they support:

  8.0: everything works
  7.4: everything works
  7.3: setTime()->timetz, setTimestamp()->time fail
  7.2: setTime()->timetz, setTimestamp()->time, +1300 timezones fail

The problem with setTime() on timetz is that we can't pass the timezone
down in <=7.3 in case it's actually a time value that is expected, so
the timetz will always end up with the server's TimeZone regardless of
the Calendar passed.

A similar problem affects setTimestamp() as it must pass a timezone down
in case the expected type is timestamptz, which will fail if the
expected type is actually time.

We can't fix these cases by asking the server for the actual type
expected, as that requires protocol v3 which 7.2/7.3 don't support.

The +1300 timezone problem is a server bug in 7.2 (possibly fixed in
later 7.2 releases, haven't checked); +1300 is a legal timezone but 7.2
doesn't accept it.

Oid.UNKNOWN is now used for setTimestamp() and setDate(). It's
unfortunately necessary for setDate() to handle setDate(i,date,calendar)
when the underlying column is a timestamptz, for much the same reasons
as the timestamp/timestamptz issue -- we need to avoid an unwanted
rotation by the server's TimeZone setting.

Cleaned up some of the tests in TimestampTest so they don't break when
the JVM's timezone is different to the server's timezone.

Still broken: CallableStatement.get{Date,Time,Timestamp} with Calendar.
Fixing this will like require some rearrangement of when OUT parameters
are turned into Objects.