Ken Johanson wrote:
> Oliver Jowett wrote:
>> Ken Johanson wrote:
>>
>>> So, short of passing a calendar to setTimezone, there is no other way
>>> to indicate to the driver that zone-less date/time type values should
>>> be translated to the server's different timezone, is this correct?
>>
>> You could change the client JVM's default timezone I suppose.
>>
>> I still don't understand exactly what you are trying to do, though.
>>
>
> I could probably summarize it best by saying that I would like to place
> all the server-specific info (including timezone) into the connection
> URL, and leave the app to only pass what it and the jvm otherwise
> considers to be a implicit/local timestamp.
>
> To put it another way, Timestamp being a long integer, a point in time
> that is the same anywhere, and we let the driver and database(s)
> connectivity implicitly handle it's string nature in sql/iso8601.
>
> This is useful where plural databases (not under my control) may exist
> each in different timezones, and the app must deal with each
> concurrently; where storing server configs (separate from the URL) and
> passing Calendar objects for each, could be avoided.
But if you are using timestamp-without-timezone in each database, I
don't understand why the server timezone comes into the equation at all?
04:05 as a ts-without-tz in any database is going to end up as 04:05 in
the client JVM's default timezone regardless of what the server timezone is.
If you want to identify absolute points in time (as Timestamp does) then
you should be using timestamp with timezone, surely? The datatype name
is somewhat misleading: it doesn't actually store timezone info at all,
it actually identifies a unique point in time, and then represents that
in whatever timezone you request - i.e. it's a much better match to
java.sql.Timestamp than ts-without-timezone is.
Can you give me some concrete examples of schema + app code and how you
would want it to behave?
-O
