John Lister wrote:
> However in TimestampUtils.getTime, this is initially done, but then
> reversed further down and the supplied timezone is used as follows:
>
> if (ts.hasDate) {
> // Rotate it into the requested timezone before we zero out
> the date
> .....
> cal.setTime(new Date(useCal.getTime().getTime()));
> useCal = cal;
> }
>
> is there a reason for this as it seems inconsistent with getTimestamp
> and the api docs?
I believe this is necessary so that the Time type's invariants (that
day/month/year is Jan 1 1970 in the specified timezone) are satisfied.
The driver extends the interpretation of getTime(int,Calender) to mean
that the returned Time object will be valid for the specified Calendar,
regardless of whether a timezone was present in the underlying DB or not.
The underlying timezone, if present, is still used when constructing a
milliseconds value, but the driver then rotates that resulting value
into the target timezone. If we don't do that then you get the strange
result that retrieving a time "01:35:42" while providing a Calendar will
result in a Time object that does not display as 01:35:42 if you format
it with that same Calendar. (I hesitate to say whether this is right or
wrong, because as usual JDBC is woefully underspecified in this area,
but it's certainly confusing at a minimum)
-O