Valeur par défaut invalide pour le champ d’horodatage ‘create_date’

C’est à cause du mode SQL du serveur – NO_ZERO_DATE .

De la référence: NO_ZERO_DATE – En mode ssortingct, n’autorisez pas la date '0000-00-00' . Vous pouvez toujours insérer des dates zéro avec l’option IGNORE . Lorsqu’elle n’est pas en mode ssortingct, la date est acceptée mais un avertissement est généré.

Si vous avez généré le script à partir de MySQL Workbench.

La ligne suivante est générée

 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL,ALLOW_INVALID_DATES'; 

Supprimer TRADITIONAL de SQL_MODE, puis le script devrait fonctionner correctement

Sinon, vous pouvez définir le SQL_MODE comme autoriser les dates non valides

 SET SQL_MODE='ALLOW_INVALID_DATES'; 

TIMESTAMP a une plage de ‘1970-01-01 00:00:01’ UTC à ‘2038-01-19 03:14:07’ UTC (voir doc ). La valeur par défaut doit être comprise dans cette plage.

Autre comportement étrange, lié:

 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) 

Note latérale, si vous voulez insérer NULLS:

 CREATE TABLE tbl4 ( ts TIMESTAMP NULL DEFAULT NULL); 

Dans Ubuntu Desktop 16.04, j’ai fait ceci:

1. Ouvrez le fichier: /etc/mysql/mysql.conf.d/mysqld.cnf dans un éditeur de votre choix.

2. Cherchez: sql_mode , ce sera quelque part sous [mysqld] .

3. et définissez sql_mode comme suit:

   NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

4. Enregistrez puis redémarrez le service mysql en procédant comme suit:

   sudo service mysql restart

En utilisant OS X , installez mysql à partir de Homebrew , Variables système basées sur ses valeurs par défaut compilées. La solution consiste à supprimer “NO_ZERO_DATE” des variables système “sql_mode”.

Gardez simplement à l’esprit que la scope implique.

Si vous souhaitez affecter uniquement à votre session, veuillez utiliser "@@session" , par exemple:

 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". 

Dans ce cas, cela n’affectera pas une fois votre session terminée ou votre modification. Cela n’a pas d’effet sur les autres sessions.

Si vous souhaitez affecter sur tous les clients, veuillez utiliser "@@global" , par exemple:

 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". 

Dans ce cas, cela n’affecte que les clients qui se connectent après la modification (n’affecte pas tous les clients actuels) et ne fonctionnera pas une fois que le serveur sera sorti.

J’ai pu résoudre ce problème sous OS X en installant MySQL à partir de Homebrew

 brew install mysql 

en ajoutant ce qui suit à /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 

et redémarrage de MySQL

 brew tap homebrew/services brew services restart mysql 

J’ai eu un problème similaire avec MySQL 5.7 avec le code suivant:

`update_date` TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP

J’ai corrigé en utilisant à la place:

`update_date` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP

Pour éviter ce problème, vous devez supprimer NO_ZERO_DATE de la configuration du mode mysql.

1. Allez dans “phpmyadmin”.
2. Une fois phpmyadmin chargé, cliquez sur l’onglet “variables”.
3. Recherchez ‘sql mode’.
4. Cliquez sur l’option Modifier et supprimez NO_ZERO_DATE (et sa virgule NO_ZERO_DATE ) de la configuration.

C’est un problème très courant dans l’environnement local avec wamp ou xamp.

Vous voudrez peut-être examiner le paramètre de fuseau horaire sur l’instance MySql:

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

dans mon cas, je me suis rendu compte que le fuseau horaire du système sous-jacent était défini sur BST plutôt que sur UTC, et que dans la table de création, la valeur par défaut était «1970-01-01 00:00:01» une valeur d’horodatage invalide.

Pour moi, je voulais en fait que le fuseau horaire de la machine soit réglé sur UTC, ce qui m’a bien aidé. Comme je dirigeais Centos / 7, j’ai simplement fait

 # timedatectl set-timezone UTC 

et tout redémarré.

Pour désactiver le mode SQL ssortingct

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

Dans le fichier, entrez ces deux lignes:

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

Enfin, redémarrez MySQL avec cette commande:

 sudo service mysql restart 

Vous pouvez simplement changer ceci:

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

À quelque chose comme ça:

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

Les valeurs par défaut doivent commencer à partir de l’an 1000.

Par exemple,

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

J’espère que cela aide quelqu’un.