From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
---|---|
To: | John Lister <john(dot)lister-ps(at)kickstone(dot)com> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: getTiIme/Timestamp with TimeZone inconsistency |
Date: | 2009-05-04 00:43:57 |
Message-ID: | 49FE3A4D.5050704@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
John Lister wrote:
> I agree the JDBC spec is vague, but I read the spec such that the
> supplied calendar is *only* used if the server doesn't support a
> timezone. I think my main concern is that setTimestamp behaves
> differently to setTime. I'm not sure which is correct (i'd tend to the
> former) but i think they should behave the same...
The problem is that there's a bit of a disconnect between the server's
idea of time / timestamp with or without timezone, and the Java
representations. java.sql.Time is just a hideous hack to begin with.
It's going to be at best a patch job getting them to fit together.
> I'm not sure what the correct behaviour should be if the server has a
> timezone and you specify one to use. Hopefully the app writer would only
> use this case for none timezone columns/results.... maybe too much to
> ask for :)
I'm reluctant to touch that date/time handling code without an actual
testcase showing a problem. It's quite fragile as it is, and small
changes can have unintended consequences :/
-O
From | Date | Subject | |
---|---|---|---|
Next Message | Péter Kovács | 2009-05-04 08:27:02 | Re: Very strange performance decrease when reusing a PreparedStatement |
Previous Message | Kris Jurka | 2009-05-04 00:32:30 | Re: Unit test patches |