BUG #5747: TimeStamps too far into the future are invalid
The following bug has been logged online:
Bug reference: 5747
Logged by: Kurt Stam
Email address: kstam@apache.org
PostgreSQL version: 8.3
Operating system: OSX
Description: TimeStamps too far into the future are invalid
Details:
https://issues.apache.org/jira/browse/JUDDI-374
When the coverage period goes out too far postgres has issues. The coverage
periods are specified in the uddi-tck-base module in the directory
src/main/resources/uddi_data/subscription; the files
subscriptionresults3.xml and subscriptionresults4.xml:
Changing the endPoint from 2100 to 2030.
This is clearly a bug in postgres or the postgres driver. On saving no error
is thrown, however the endpoint field is set to 'invalid' which is an issue
when the date is parsed back into a timedate.
"Kurt Stam" <kstam@apache.org> writes:
There is no evidence whatsoever on that page to demonstrate that there's
any such postgresql bug. What's more, simple testing suggests that PG
is perfectly happy with timestamps of 2100 or even further out. If
you'd like us to believe we have something to fix, please exhibit some
SQL commands that deliver an incorrect result.
regards, tom lane
tgl@sss.pgh.pa.us (Tom Lane) writes:
There's an issue that JDBC doesn't cope very well with 'Infinity'
values, which is more or less the opposite of what's reported here. I
have been tending to put "don't allow +/-Infinity" constraints onto
timestamps to avoid that particular impedance mismatch.
Just ran a little test of this with...
PostgreSQL 8.3.3, last year's JDBC, and had no difficulties pushing in
the date "2100-01-01 00:00:00".
That suggests the problem to be elsewhere. (As, I expect, you would
expect!)
--
(format nil "~S@~S" "cbbrowne" "gmail.com")
Rules of the Evil Overlord #194. "I will make several ludicrously
erroneous maps to secret passages in my fortress and hire travellers
to entrust them to aged hermits." <http://www.eviloverlord.com/>