From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dave Cramer <pg(at)fastcrypt(dot)com> |
Cc: | Christopher BROWN <brown(at)reflexe(dot)fr>, List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: PreparedStatement.setDate() behavior with OVERLAPS |
Date: | 2015-08-11 15:00:09 |
Message-ID: | 20415.1439305209@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Dave Cramer <pg(at)fastcrypt(dot)com> writes:
> Here are the comments in the code.
> // We must use UNSPECIFIED here, or inserting a Date-with-timezone into a
> // timestamptz field does an unexpected rotation by the server's TimeZone:
Ugh. But why not send it as a timestamptz?
(I suspect that the law of conservation of astonishment applies, such that
some other corner cases would act oddly if you do that. But it might be
a net improvement anyway.)
> Apparently while dates don't store timezone information we do accept
> timezone info in date literals ?
Sure. Times, too. The same input parser is used for date, timestamp,
timestamptz, time, and timetz, and then we just throw away irrelevant
fields.
regression=# select '2015-08-11 10:55:04.509393-04'::date;
date
------------
2015-08-11
(1 row)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2015-08-11 15:03:09 | Re: PreparedStatement.setDate() behavior with OVERLAPS |
Previous Message | Dave Cramer | 2015-08-11 14:52:12 | Re: PreparedStatement.setDate() behavior with OVERLAPS |