Re: JDBC/TIMESTAMP/infnity question

Поиск
Список
Период
Сортировка
От Moran, William
Тема Re: JDBC/TIMESTAMP/infnity question
Дата
Msg-id 4D557EC7CC2A544AA7C1A3B9CBA2B36724E70E538B@exchange03.epbs.com
обсуждение исходный текст
Ответ на JDBC/TIMESTAMP/infnity question  ("Moran, William" <William.Moran@intermedix.com>)
Список 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 по дате отправления:

Предыдущее
От: David Johnston
Дата:
Сообщение: Re: A prepared statement ERROR due to EMPTY_QUERY is defined as a static Instance.
Следующее
От: Dave Cramer
Дата:
Сообщение: Re: Re: A prepared statement ERROR due to EMPTY_QUERY is defined as a static Instance.