JDBC Timestamp & Date GMT выпускает

Question

У меня есть столбец JDBC Date, который, если я использую getDate, получает только часть ' date ' 02 октября 2009 , но если я использую getTimestamp, я получаю полное значение * дата ' 02 октября 2009 г. 13: 56: 78: 890 . Это именно то, что я хочу.

Однако «дата», возвращаемая getTimestamp, «игнорирует» значения GMT, предположим, дата; 02 октября 2009 г. 13: 56: 78: 890 , в итоге я получаю 02 октября 2009 г. 15: 56: 78: 890

Моя дата была сохранена как + 2GMT в базе данных, но сервер приложений в GMT, т.е. на 2 часа меньше

Как все еще можно получить мою дату как есть, 02 октября 2009 г. 13: 56: 78: 890

Редактировать

Я получаю дату +2 на стороне клиента по Гринвичу + 2

Answer 1

В этом разница между меткой времени и другими временными типами в MySQL. Отметка времени сохраняется в формате UIX time_t в UTC, но другие типы хранят дату / время буквально без информации о зоне.

Когда вы вызываете getTimestamp (), драйвер JDBC MySQL преобразует время из GMT в часовой пояс по умолчанию, если тип является меткой времени. Он не выполняет такого преобразования для других типов.

Вы можете изменить тип столбца или выполнить преобразование самостоятельно. Я рекомендую прежний подход.

Answer 2

Вы должны знать, что java.util.Date (а также java.sql.Date и java.sql.Timestamp, которые являются подклассами java.util.Date) ничего не знают о часовых поясах, или, скорее, они всегда находятся в UTC.

java.util.Date и его подклассы являются не более чем контейнером для значения «количество миллисекунд с 01-01-1970, 12:00 AM UTC».

Чтобы отобразить дату в определенном часовом поясе, преобразуйте ее в строку, используя объект java.text.DateFormat. Установите часовой пояс для этого объекта, вызвав метод setTimeZone(). Например:

Date date = ...;  // wherever you get this from

DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

// Make the date format show the date in CET (central European time)
df.setTimeZone(TimeZone.getTimeZone("CET"));

String text = df.format(date);

Answer 3

Однажды я столкнулся с подобной проблемой, когда компонент времени урезался по некоторым датам.

Мы сократили разницу в версиях драйверов Oracle.

В FAQ Oracle есть раздел об этом:

---

select sysdate from dual; ...while(rs.next())

До 9201 г. возвращается: getObject для sysdate: java.sql.Timestamp <<<< getDate для sysdate: java.sql.Date getTimetamp для sysdate: java.sql.Timestamp </p>

Начиная с 9201 года будет возвращено следующее

getObject для sysdate: java.sql.Date <<<<< getDate для sysdate: java.sql.Date >> без изменений getTimetamp для sysdate: java.sql.Timestamp >> без изменений

Примечание: java.sql.Date не имеет временной части, тогда как java.sql.Timestamp делает.

С этим изменением в отображении типа данных, некоторые приложения не будут работать и / или будут выдавать неправильные результаты при обновлении драйвера JDBC с 8i / 9iR1 до 920x драйвера JBDC. Для обеспечения совместимости и обеспечения работы приложений после обновления был предоставлен флаг совместимости. У разработчиков теперь есть несколько вариантов:

1. Используйте флаг oracle.jdbc.V8Compatible.

Драйвер JDBC по умолчанию не определяет версию базы данных. Чтобы изменить флаг совместимости для обработки типов данных TIMESTAMP, свойство соединения

'oracle.jdbc.V8Compatible'

может быть установлено в значение «истина», и драйвер ведет себя так же, как и в 8i, 901x, 9 200 (относительно TIMESTAMP).

По умолчанию флаг установлен на «ложь». В конструкторе OracleConnection драйвер получает версию сервера и соответствующим образом устанавливает флаг совместимости.

java.util.Properties prop=newjava.util.Properties(); 
prop.put("oracle.jdbc.V8Compatible","true"); 
prop.put("user","scott"); 
prop.put("password","tiger");
String url="jdbc:oracle:thin:@host:port:sid"; 
Connection conn = DriverManager.getConnection(url,prop);

В JDBC 10.1.0.x вместо свойства соединения может использоваться следующее системное свойство: java -Doracle.jdbc.V8Compatible = true ..... Примечание. Этот флаг является флагом только клиента, который управляет метка времени и дата. Это не влияет на любую функцию базы данных.

2. Используйте set / getDate и set / getTimestamp при работе с типом данных столбца Date и TimeStamp соответственно.

Сервер 9i поддерживает типы столбцов Date и Timestamp. DATE сопоставляется с java.sql.Date, а TIMESTAMP сопоставляется с java.sql.Timestamp.

---

Итак, для моей ситуации у меня был такой код:

import java.util.Date; 
Date d = rs.getDate(1);

С 9i я получал java.sql.Timestamp (который является подклассом java.util.Date), поэтому все было отлично, и у меня были часы и минуты.

Но с 10g тот же код теперь получает java.sql.Date (также подкласс java.util.Date, поэтому он все еще компилируется), но HH: MM TRUNCATED !!.

2-е решение было довольно простым для меня - просто замените getDate на getTimestamp, и все будет в порядке. Я думаю, это была плохая привычка.

Answer 4

private Date convertDate(Date date1) throws ParseException {
        SimpleDateFormat sdfFormatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
        String dateStr = sdfFormatter.format(date1);
        SimpleDateFormat sdfParser = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
        sdfParser.setTimeZone(TimeZone.getTimeZone("GMT"));
        return sdfParser.parse(dateStr);
    }

Answer 5

Из этого поста я пришел к выводу, что JDBC извлекает часовой пояс для временной метки (я не думаю, что MS SQL также поддерживает это, большинство результатов Google указывают на Oracle)

Когда вызывается метод getDimeStamp JDBC, он получает только часть 'миллисекунд ' и создает объект Date с сервером TimeZone, который является GMT.

Когда этот объект Date представлен моему клиенту, который находится в +2 по Гринвичу, он добавляет 2 часа, что является стандартным смещением, которое приводит к дополнительным часам.

Я исправил это, удалив временное смещение из даты, которую я получаю, т.е. преобразовал в истинную дату по Гринвичу.