Thread: 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: > https://issues.apache.org/jira/browse/JUDDI-374 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: > https://issues.apache.org/jira/browse/JUDDI-374 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/>