MySQL: усечение данных: неверное значение даты и времени: '2006-10-01 02:22:44'

Question

Я получаю следующее исключение при обновлении строки с использованием MySQL через JDBC:

com.mysql.jdbc.MysqlDataTruncation: усечение данных: неверное значение даты и времени: '2006-10-01 02:22: 44 '

Столбец определен как:

' created_on_service отметка времени NULL DEFAULT NULL '

Нет индексовили внешние ключи в этом столбце.

Очевидно, что это не проблема с типом данных.У меня есть значения в этой таблице как до, так и после этой даты.У меня также есть значения со временем до и после 2:22.

Answer 1

Решено.

Оказывается, что 1 октября 2006 года в Южной Австралии стало началом перехода на летнее время.Часы переводятся на час вперед в 2 часа ночи, поэтому в этот день не было 2:22 утра: они шли прямо с 2:00 до 3:01 утра.должен решить эту проблему.

Answer 2

Я исправил ту же проблему (com.mysql.jdbc.MysqlDataTruncation: Data truncation: Incorrect datetime value: '' for column 'perev_start_time' at row 1), обновив JAR-файл коннектора MySQL и скопировав mysql.jar в каталог lib Tomcat.

Версия MySQL Server 5.6, а коннектор MySQL -mysql-connector-java-5.1.30-bin.jar.

Answer 3

Мы обновили сервер MySQL, но не обновили jar коннектора mysql. Мы столкнулись с этой проблемой. Позже я понял, что это из-за старой банки. Я обновил его, и эта проблема исчезла.

Answer 4

Моя проблема была вызвана DST тоже.Я исправил это, изменив тип данных столбца с timestamp на datetime.Этот ответ описывает разницу, вкратце:

• отметка времени сохраняет время как время эпохи Unix , поэтому преобразует его в / изUTC в соответствии с часовым поясом сервера.После изменения часового пояса сервера у вас будет другая интерпретация для INSERT / UPDATE и другие результаты SELECT.Некоторые временные точки недействительны из-за перехода на летнее время;
• datetime сохраняет время как есть, независимо от часового пояса сервера.При прохождении времени UTC, любое время является действительным (нет «дыр» в DST).

Примечание: вам, возможно, все равно придется иметь дело с «пропущенным» временем.Этот подход просто переносит ответственность с уровня БД на уровень приложения.

См. Также: Документация MySQL для TIMESTAMP vs DATETIME

Answer 5

Вы не показали точное обновление SQL.Но, может быть, вы забыли часть даты

Правильный формат: гггг-мм-дд чч: мм: сс формат

Значение даты должно быть в следующем формате 2011-11-01 12:32: 01