Inconsistency between JDBC and ODBC drivers when dealing with TIMESTAMP WITH TIME ZONE
От | Walter Couto |
---|---|
Тема | Inconsistency between JDBC and ODBC drivers when dealing with TIMESTAMP WITH TIME ZONE |
Дата | |
Msg-id | 7FA4F9E5512F214C801E596ECD8790E066A82A9A@ETNAMAIL01.embarcadero.com обсуждение исходный текст |
Ответы |
Re: Inconsistency between JDBC and ODBC drivers when dealing
with TIMESTAMP WITH TIME ZONE
Re: Inconsistency between JDBC and ODBC drivers when dealing with TIMESTAMP WITH TIME ZONE |
Список | pgsql-odbc |
CREATE TABLE DATE_TEST ( test integer NOT NULL, TIMESTAMPOFFSET_COL TIMESTAMP WITH TIME ZONE, PRIMARY KEY(TEST) ) ; INSERT INTO DATE_TEST VALUES ( 2, timestamp WITH TIME ZONE '2002-04-11 01:33:08.12345+02' ); ; NOTE: My client machines time zone offset is currently -4. The server's times zone offset is +3. Execute: select TIMESTAMPOFFSET_COL from DATE_TEST where test = 2. Results: If you bind to that column as a timestamp, I get the following: JDBC: 2002-04-11 19:33:08.12345 ODBC: 2002-04-11 02:33:08.12345 If I bind as a string I get: JDBC: 2002-04-10 19:33:08.12345-04 ODBC: 2002-04-11 02:33:08.12345 The fact the two drivers return completely different results is a concern as they both should behave the same for this datatype for consistency, but I can work around that via the string binding if the time zone is returned....but ODBC cannever give me the time zone! I think this is a serious bug. I can work around this by assuming the same time zone asthe server, but I would then have to keep checking what that time zone offset is just in case the session time zone changed,but I think this is a waste of a query round trip since that info should have been available to me via binding asa string. Regards, Walter CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidentialand privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you arenot the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
В списке pgsql-odbc по дате отправления: