From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Do, Leon \(Leon\)" <leondo(at)alcatel-lucent(dot)com> |
Cc: | "Kris Jurka" <books(at)ejurka(dot)com>, "Oliver Jowett" <oliver(at)opencloud(dot)com>, "Dave Cramer" <pg(at)fastcrypt(dot)com>, "imad" <immaad(at)gmail(dot)com>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: help with front/backend datatype converting |
Date: | 2007-01-06 03:30:22 |
Message-ID: | 25794.1168054222@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
"Do, Leon \(Leon\)" <leondo(at)alcatel-lucent(dot)com> writes:
> It can takes any input. You cann't assume it only return hh:mm.
Yes you can --- see EncodeTimezone(). I concur with Kris' opinion
that the driver need not cater for output formats the server will
never generate. Especially not if it's explicitly setting DateStyle,
as I seem to remember it does.
One thing that possibly *does* need fixed as of 8.2 is that the server
can generate hh:mm:ss if the timezone has a fractional-minute UTC
offset. I do not believe there are any modern timezones that do, but
quite a lot do if you check dates 100 or so years ago.
regression=# set timezone = 'Europe/Dublin';
SET
regression=# select now() - '100 years'::interval;
?column?
-------------------------------------
1907-01-06 03:28:22.483631-00:25:21
(1 row)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mikko Tiihonen | 2007-01-07 18:55:01 | Binary protocol patch v7 |
Previous Message | Do, Leon (Leon) | 2007-01-05 21:58:04 | Re: help with front/backend datatype converting |