Обсуждение: JDBC/TIMESTAMP/infnity question

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?

Bill Moran, System Architect
Phone: 412-422-3463x4023
http://www.intermedix.com

The information contained in this message is confidential and may be
privileged and/or protected under law. If you received this message in
error, please notify us immediately by forwarding a copy to
compliance@intermedix.com and then deleting the original message and
any attachments.

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?