Re: Re: Inconsistency between JDBC and ODBC drivers when dealing with TIMESTAMP WITH TIME ZONE

On 06/09/2014 07:49 PM, Walter Couto wrote:
> I have to strongly disagree that this is an enhancement.  It is a severe bug. In PostgreSQL, if you look at both the
JDBCand ODBC source code, for timestamp with time zone, the string that the server gives to the driver for my example
is"2002-04-11 02:33:08.12345+3"  if the session time zone is set to +3. 
>
> Asking for a timestamp with time zone as a timestamp in either ODBC and JDBC is done knowing you are accepting the
loseof time zone info. I have NO issue with this (as a side note the JDBC and ODBC driver did behave the same at one
point,in both cases they returned the timestamp in the server time zone, but surprise change in a recent version to
correctthis to be JDBC spec compliant caused some headaches for some people using the driver as they wrote code
assumingthis behaviour and now were all wrong). 
>
> I have an issue with the retuned string value from ODBC....the driver got a perfectly fine string, it could have
givenit to me. There is no sane reason to have the time zone part stripped out before giving it to me.  At least with
JDBCit gave me an EQUALLY ACCURATE string of "2002-04-10 19:22:08.12345-04", with ODBC I need to run a separate query
toget the session time zone to correct the string that was perfectly fine when ODBC was given it. 
>
> Changing the query is nice for internal queries and is a good work around for this bug, but when non-internal queries
aregiven to our application, we can't expect to ask the customers to work around driver bugs and change all their
perfectlyworking queries. I expect the driver to give information as accurately as the server gave to the driver.  That
iswhat I am asking here and that is what is not happing in the case of ODBC when asking for the string form of a
timestampwith time zone.  This is why I see this as a severe bug as the driver is giving me CORRUPT data that is not
thesame or even equally the same as the data it retrieved from the server that the client tool has to "fix" by issuing
anotherquery. 


You still have not shown what it is you are actually doing. Personally,
less rant and more actual code would be useful. You originally asked for
a solution and I would like to see that, but at this point there is not
enough information to go on, for me at least.

So what exactly do you mean when you say 'asking for string form of
timestamp with time zone'?

>
> Regards,
> Walter


--
Adrian Klaver
adrian.klaver@aklaver.com