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
