Re: PreparedStatement.setDate() behavior with OVERLAPS
От | Dave Cramer |
---|---|
Тема | Re: PreparedStatement.setDate() behavior with OVERLAPS |
Дата | |
Msg-id | CADK3HHKZcCOQkbtwiRGfOK0nKRX5DzPnzM_DaOL+B8RM8mjh5A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PreparedStatement.setDate() behavior with OVERLAPS (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PreparedStatement.setDate() behavior with OVERLAPS
|
Список | pgsql-jdbc |
// We must use UNSPECIFIED here, or inserting a Date-with-timezone into a
// timestamptz field does an unexpected rotation by the server's TimeZone:
//
// We want to interpret 2005/01/01 with calendar +0100 as
// "local midnight in +0100", but if we go via date it interprets it
// as local midnight in the server's timezone:
// template1=# select '2005-01-01+0100'::timestamptz;
// timestamptz
// ------------------------
// 2005-01-01 02:00:00+03
// (1 row)
// template1=# select '2005-01-01+0100'::date::timestamptz;
// timestamptz
// ------------------------
// 2005-01-01 00:00:00+03
// (1 row)
Apparently while dates don't store timezone information we do accept timezone info in date literals ?
It strikes me that maybe the root problem is that Christopher is doing
things in such an order that the server is asked to parse the SQL string
before the setDate() is done. Don't know enough details about JDBC to
translate that idea into code, though.
regards, tom lane
В списке pgsql-jdbc по дате отправления: