Недопустимое значение по умолчанию для поля timestamp 'create_date'

Ответ 1

Это из-за SQL-режима сервера - NO_ZERO_DATE.

Из справки: NO_ZERO_DATE - В строгом режиме не разрешайте '0000-00-00' как действительную дату. Вы можете вставить нулевые даты с опцией IGNORE. Если не в строгом режиме, дата принимается, но генерируется предупреждение.

Ответ 2

Если вы сгенерировали скрипт из рабочей среды MySQL.

Следующая строка генерируется

SET @[email protected]@SQL_MODE, SQL_MODE='TRADITIONAL,ALLOW_INVALID_DATES';

Удалите TRADITIONAL из SQL_MODE, и тогда скрипт должен нормально работать

Иначе, вы можете установить SQL_MODE как Разрешить недопустимые даты

SET SQL_MODE='ALLOW_INVALID_DATES';

Ответ 3

TIMESTAMP имеет диапазон '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC (см. doc). Значение по умолчанию должно быть в этом диапазоне.

Другие нечетные, связанные, поведение:

CREATE TABLE tbl1 (
    ts TIMESTAMP);  
Query OK, 0 rows affected (0.01 sec)

CREATE TABLE tbl2 (
    ts TIMESTAMP,
    ts2 TIMESTAMP);
ERROR 1067 (42000): Invalid default value for 'ts2'

CREATE TABLE tbl3 (
    ts TIMESTAMP,
    ts2 TIMESTAMP DEFAULT '1970-01-01 00:00:01');
Query OK, 0 rows affected (0.01 sec)

Обратите внимание, если вы хотите вставить NULLS:

CREATE TABLE tbl4 (
    ts TIMESTAMP NULL DEFAULT NULL);

Ответ 4

В Ubuntu Desktop 16.04 я сделал это:

1. Откройте файл: /etc/mysql/mysql.conf.d/mysqld.cnf в /etc/mysql/mysql.conf.d/mysqld.cnf редакторе.

2. Ищите: sql_mode, он будет где-то под [mysqld].

3. и установите sql_mode в следующее:

   NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

4. Сохраните и перезапустите службу MySQL, выполнив:

   sudo service mysql restart

Ответ 5

Используя OS X, установите mysql из Homebrew, системные переменные, основанные на своих скомпилированных значениях по умолчанию. Решение состоит в том, чтобы удалить "NO_ZERO_DATE" из системных переменных "sql_mode".

Просто имейте в виду, что область охвата включает.

Если вы хотите повлиять только на свой сеанс, используйте "@@session", например:

SET @@session.sql_mode ="ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION".

В этом случае это не повлияет на завершение сеанса или на его изменение. Это не влияет на другую сессию.

Если вы хотите повлиять на всех клиентов, используйте "@@global", например:

SET @@global.sql_mode ="ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION".

В этом случае это влияет только на клиентов, которые подключаются после изменения (не влияют на текущих всех клиентов) и не будут работать после выхода сервера.

Ответ 6

Я смог решить эту проблему в OS X, установив MySQL из Homebrew

brew install mysql

добавив следующее в /usr/local/etc/my.cnf

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

и перезапуск MySQL

brew tap homebrew/services
brew services restart mysql

Ответ 7

У меня была аналогичная проблема с MySQL 5.7 со следующим кодом:

`update_date` TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP

Я исправил, используя это вместо:

`update_date` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP

Ответ 8

Чтобы избежать этой проблемы, вам нужно удалить NO_ZERO_DATE из конфигурации режима mysql.

1. Перейти к phpmyadmin.
2. После загрузки phpmyadmin, нажмите на вкладку "переменные".
3. Ищите "sql mode".
4. Нажмите на опцию Edit и удалите NO_ZERO_DATE (и его запятую) из конфигурации.

Это очень распространенная проблема в локальной среде с wamp или xamp.

Ответ 9

Вам может потребоваться изучить настройку часового пояса в экземпляре MySql:

mysql> show variables like 'time_zone';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| time_zone     | SYSTEM |
+---------------+--------+

в моем случае я понял, что базовая система установила часовой пояс на BST, а не на UTC, и поэтому в таблице create по умолчанию "1970-01-01 00:00:01" было принудительно возвращено 1 час, что приводит к недопустимому значению метки времени.

Для меня я действительно хотел, чтобы часовой часовой пояс установлен в UTC, и это меня разобрало. Когда я запускал Centos/7, я просто делал

# timedatectl set-timezone UTC

и перезапустили все.

Ответ 10

Чтобы отключить строгий режим SQL

Create disable_strict_mode.cnf file at /etc/mysql/conf.d/

В файле введите следующие две строки:

[mysqld]
sql_mode=IGNORE_SPACE,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

Наконец, перезапустите MySQL с помощью этой команды:

sudo service mysql restart

Ответ 11

пожалуйста, перейдите к вашему phpmyadmin выбрать базу данных выбрать таблицу теперь goto таблица структура вы можете увидеть здесь в столбце по умолчанию current_timestamp теперь измените dafaults нажмите на столбец "action" → table-column- > change в столбце по умолчанию выберите none я думаю, ваша проблема решена

Ответ 12

Вы можете просто изменить это:

'create_date' TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00',

Чтобы что-то вроде этого:

'create_date' TIMESTAMP NOT NULL DEFAULT '2018-04-01 12:00:00',

Ответ 13

Значения по умолчанию должны начинаться с 1000 года.

Например,

ALTER TABLE mytable last_active DATETIME DEFAULT '1000-01-01 00:00:00'

Надеюсь, это кому-нибудь поможет.

Ответ 14

Самое смешное изменение когда-либо, мистер MySQL. Если поле даты пустое и вводить значение, когда это необходимо, это нормально, но нет, у вас должна быть нелепая запись, начиная с> года 1001, но я использовал поле даты поддержки уже 15 лет, которое вводится только тогда, когда пользователь получает билет поддержки и получает 1 месяц. Но теперь я изменяю это поле на VARCHAR. Какая кучка идиотов! И мы, люди, должны с этим работать.

Ответ 15

На одном сервере с версией 5.1.73 мне пришлось использовать '1970-01-02 00:00:01', а не '1970-01-02 00:00:01'

С другой стороны, '1970-01-02 00:00:01' работал нормально!

Оба не имели значения для переменной sql_mode.