ResultSet.getTimestamp ("date") против ResultSet.getTimestamp ("date", Calendar.getInstance (tz)) - PullRequest
Новая
       25

ResultSet.getTimestamp ("date") против ResultSet.getTimestamp ("date", Calendar.getInstance (tz))

10 голосов
/ 06 апреля 2010

java.util.Date, java.util.Timetamp, похоже, вызывали у многих смятение. В StackOverflow столько вопросов, к сожалению, мой вопрос немного искажен.

Существует 2 API JDBC. Как они должны выполнять? Была ли какая-либо согласованность среди СУРБД? 

ResultSet.getTimestamp("dateColumn") 
ResultSet.getTimestamp("dateColumn", Calendar.getInstance(tz))

Если у кого-то есть знания в Sybase, не могли бы вы поделиться своим опытом?

1 Ответ

26 голосов
/ 06 апреля 2010

Во-первых, вы путаете java.util с java.sql. При использовании PreparedStatement#setDate() и ResultSet#getDate() необходимо java.sql.Date. Аналогично, при использовании PreparedStatement#setTimestamp() и ResultSet#getTimestamp() нужно java.sql.Timestamp.

Во-вторых, важно понимать, что java.sql.Date представляет собой только дату (год, месяц, день) и ни меньше, ни больше. Это должно быть сопоставлено с типом поля SQL DATE. java.sql.Timestamp представляет отметку времени (год, месяц, день, час, минута, секунда, миллисекунда), точно так же, как java.util.Date и java.util.Calendar делает Это должно быть сопоставлено с типом поля SQL TIMESTAMP или DATETIME.

Что касается часовых поясов, он вам нужен, когда база данных не хранит информацию о часовом поясе (таким образом, все временные метки хранятся в UTC (GMT)). Затем вы можете передать Calendar, в котором содержится информация о текущем часовом поясе, чтобы драйвер JDBC мог настроить временную метку UTC на временную метку, соответствующую часовому поясу. Если это, например, GMT + 1, то драйвер JDBC добавит один час к отметке времени перед возвратом.

...