Re: JDBC/TIMESTAMP/infnity question - Mailing list pgsql-jdbc

From Moran, William
Subject Re: JDBC/TIMESTAMP/infnity question
Date
Msg-id 4D557EC7CC2A544AA7C1A3B9CBA2B36724E70E538B@exchange03.epbs.com
Whole thread Raw
In response to JDBC/TIMESTAMP/infnity question  ("Moran, William" <William.Moran@intermedix.com>)
List pgsql-jdbc
For anyone who happens to find this via google search:

I did a little research and experimenting and found the answer.  Java
doesn't include the era in the String version of the date by default,
so in the example below, the date of 292269055-12-02 is actually BC,
which is pretty reasonable.

> Working with the JDBC driver and PostgreSQL TIMESAMP types, I've
> observed the following behavior, which is odd to me:

> getString('infinity'::timestamp) = "infinity"
> getString('-infinity'::timestamp) = "-infinity"
> getTimestamp('infinity'::timestamp) = 292278994-08-16 18:00:00.0
> getTimestamp('-infinity'::timestamp) = 292269055-12-02 18:00:00.0

> As best as my research can tell, the java.sql.Timestamp type doesn't
> have any concept of infinity/-infinity.  But I'm surprised -infinity
> is converted into a date far in the future instead of something in the
> past.

> Looking through the source code, it looks like the driver is trying to
> do the best it can by picking a large date in the past ... does anyone
> know why it's ending up in the future?



pgsql-jdbc by date:

Previous
From: David Johnston
Date:
Subject: Re: A prepared statement ERROR due to EMPTY_QUERY is defined as a static Instance.
Next
From: Dave Cramer
Date:
Subject: Re: Re: A prepared statement ERROR due to EMPTY_QUERY is defined as a static Instance.