Re: Regression: Problems with Timestamp arguments

From: Kris Jurka <books(at)ejurka(dot)com>
To: Vitalii Tymchyshyn <vit(at)tym(dot)im>
Cc: Lachezar Dobrev <l(dot)dobrev(at)gmail(dot)com>, PG-JDBC Mailing List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Regression: Problems with Timestamp arguments
Date: 2013-09-11 06:37:03
Message-ID: alpine.BSO.2.03.1309110220450.18392@ejurka.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

On Wed, 11 Sep 2013, Vitalii Tymchyshyn wrote:

> Why so? I thought if driver will pass timestamp with tz some queries won't
> work because of lack of implicit conversion, but I don't understand how can
> it corrupt anything.
>

It's rather complicated, but currently without knowing the datatype on the
server side, the driver must pick a datatype (timestamp with or without
timestamp or unknown) and a string representation of that data (include or
not the timezone offset). Now you can get away with this problem if the
client and server have the same timezone settings, but not if they don't.

Consider the attached test code. It prepares a statement with all three
datatype options and then executes each statement using both string
representations.

When the client and server timezones are the same, it doesn't matter what
method we use, all the results are the same. If they are different, then
only id 9 (unknown datatype, string with timezone offset) provides the
correct result for both table columns. It might be possible to work
around this by explicitly setting the server timezone or querying the
server for its timezone and making adjustments on the client side to the
data before sending it to the server.

Kris Jurka

Attachment Content-Type Size
tsbug.sql text/plain 1.6 KB

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Lachezar Dobrev 2013-09-11 07:06:02 Re: Regression: Problems with Timestamp arguments
Previous Message Thomas Kellerer 2013-09-11 06:22:37 Re: 9.3 and extended constraint error information