One other comment - if it was me implementing this thing from scratch,
here's how I'd be inclined to tackle it...
a) I'd send the timestamp value across the wire as millis (the millis
value won't change based on whether DST is turned on/off w/in the
default zone on the client) - so reading/sending as millis would mean
that the client wouldn't end up munging any dates unintentionally
simply on the basis of DST (which is a problem no)
b) I would interpret setTimestamp(i, ts, cal) as meaning "convert from
current millis to millis in cal's timezone", and then send that new
millis value across the wire
c) I'd send the timestamp across the wire as UNKNOWN, and then allow
the server to make the decision based on the column type - since the
server knows what the column is defined as, it can easily decide how
to interpret the millis value when figuring out how to actually
persist it
It seems to me this would handle all the problems we are having, while
working within the API limitations. It doesn't seem like it would
break any existing code (at least not anything that's not already
broken).
Of course, I have no idea whether any of this is feasible or not. But
I think the root of our problems is tied to flattening timestamp
objects via toString(), which then applies the calendar rendering,
which then applies DST rules of the default timezone (again, whether
you want them to or not).
One final consideration - has anyone evaluated the performance
implications of rendering/reconstituting timestamps to Strings vs.
millis? It seems to me like there must be a lot more overhead
associated with the String versions (looking up calendars, applying
dst logic, etc) than with millis.
Christian
