Ответ 1

Я обнаружил, что после обновления до MySQL 5.7 эта ошибка возникла в случайных ситуациях, даже когда я не предоставлял дату в запросе.

Это связано с тем, что предыдущие версии MySQL поддерживали даты типа 0000-00-00 00:00:00 (по умолчанию), однако 5.7.4 внесли некоторые изменения в настройку NO_ZERO_DATE. Если у вас все еще есть старые данные при использовании более новой версии MySQL, тогда могут возникнуть случайные ошибки.

Мне нужно было выполнить такой запрос до reset всех нулевых дат до другой даты.

# If the columns supports NULL, use that
UPDATE table SET date_column = NULL WHERE date_column < '1000-01-01';

# Otherwise supply another default date
UPDATE table SET date_column = '1970-01-01' WHERE date_column < '1000-01-01';

В качестве альтернативы вы можете настроить параметр NO_ZERO_DATE, хотя обратите внимание на то, что говорят о нем документы:

Режим NO_ZERO_DATE влияет на то, разрешает ли серверу "0000-00-00" в качестве допустимой даты. Его эффект также зависит от того, включен ли строгий режим SQL.

• Если этот режим не включен, "0000-00-00" разрешен, а вставки не выдают никаких предупреждений.

• Если этот режим включен, "0000-00-00" разрешен, а вставки выдают предупреждение.

• Если этот режим и строгий режим включены, "0000-00-00" не разрешается, и вставки создают ошибку, если IGNORE также не указан. Для INSERT IGNORE и UPDATE IGNORE допускается "0000-00-00" , а вставки создают предупреждение.

Начиная с MySQL 5.7.4, NO_ZERO_DATE устарел. В MySQL с 5.7.4 по 5.7.7 NO_ZERO_DATE ничего не делает, если явно указано. Вместо этого его эффект включен в эффекты строгого режима SQL. В MySQL 5.7.8 и более поздних версиях NO_ZERO_DATE имеет эффект при явном явном выражении и не входит в строгий режим, как и до MySQL 5.7.4. Однако он должен использоваться в сочетании со строгим режимом и включен по умолчанию. Предупреждение появляется, если NO_ZERO_DATE включен без включения строкового режима или наоборот. Дополнительные обсуждения см. В разделе Изменения режима SQL в MySQL 5.7.

Поскольку NO_ZERO_DATE устарел, он будет удален в будущей версии MySQL как отдельное имя режима, а его эффект включен в эффекты строгого режима SQL.

От http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmode_no_zero_date

Ответ 2

Неверное значение даты и времени Номер ошибки базы данных: 1292

Тип данных TIMESTAMP используется для значений, содержащих как дату, так и время. TIMESTAMP имеет диапазон от '1970-01-01 00:00:01' UTC до '2038-01-19 03:14:07' UTC.

Тип DATETIME используется для значений, содержащих как дату, так и время. MySQL извлекает и отображает значения DATETIME в формате 'YYYY-MM-DD HH:MM:SS'. Поддерживаемый диапазон '1000-01-01 00:00:00' to '9999-12-31 23:59:59'.

вы должны использовать этот тип в формате DateTime

INSERT INTO `activitylog` 
(`tablename`, `row`, `user_id`, `description`, `action`, `private`,`created`) 
VALUES 
('user', '1', '1', 'People', 'Updated', 0, '2014-04-02 08:49:43')

https://dev.mysql.com/doc/refman/5.0/en/date-and-time-types.html

https://dev.mysql.com/doc/refman/5.0/en/datetime.html

http://bugs.mysql.com/bug.php?id=70188

update: 1

вы должны удалить space, как ваш код '2014-04-02 08:49:43 +0000', и изменить код как '2014-04-02 08:49:43+0000', поскольку полный запрос следующий:

INSERT INTO `activitylog` 
(`tablename`, `row`, `user_id`, `description`, `action`, `private`,`created`) 
VALUES ('user', '1', '1', 'People', 'Updated', 0, '2014-04-02 08:49:43+0000')

смотрите здесь: http://sqlfiddle.com/#!2/a2581/23099

Ответ 3

Короткий ответ - NOW() в вашем запросе должен отлично работать с столбцом MySQL DATETIME.

Более длинный ответ - я не уверен, как вы когда-либо видели +0000. Столбец DATETIME отформатирован как 'YYYY-MM-DD HH:MM:SS'. Когда дело доходит до разницы в часовом поясе, обычно это то, что вам нужно для программной обработки. MySQL выполняет конвертирование локальных времен в UTC и обратно при хранении и извлечении данных TIMESTAMP, но это не делает это с помощью DATETIME или других столбцов Date/Time.

Ответ 4

Итак, у меня была такая же ошибка. То, что я сделал, чтобы исправить это, было использование этих строк кода для запроса базы данных, с которой у меня возникли проблемы:

SELECT @@GLOBAL.sql_mode global, @@SESSION.sql_mode session;
SET sql_mode = '';
SET GLOBAL sql_mode = '';

Первая строка кода (SELECT) - это то, что текущие настройки для "СЕССИИ" и "ГЛОБАЛЬНОГО". После того, как вы установили их как для пустых строк, так и для повторного выбора, они ничего не должны возвращать (быть пустыми).

Вам также может понадобиться использовать SET SESSION sql_mode = '';, но это решило проблему для меня. В принципе, один из параметров в нем поднимал способ ввода даты в базу данных (я получал ее в формате "YYYY-MM-DD HH: MM: SS AM/PM" ). Удаление NO_ZERO_IN_DATE, а другая опция даты не помогла мне.

Мой сайт работает так, как сейчас. Надеюсь, это поможет.

Ответ 5

У оригинала my.cnf был установлен sql_model следующим образом:

sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

Я попытался удалить NO_ZERO_IN_DATE и NO_ZERO_DATE, но это не повлияло. Но если я удалил все термины (sql_mode empty), ошибка исчезла.

Я вернулся к исходному sql_mode и думал, что я удалю условия 1 на 1, чтобы посмотреть, какой из них был причиной. Первой попыткой было удалить STRICT_TRANS_TABLES:

sql_mode=NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

Нет ошибки. Похоже, что причиной была STRICT_TRANS_TABLES.