Solución:
El error se debe al modo sql, que puede ser un modo estricto según la última documentación de MYSQL 5.7
La documentación de MySQL 5.7 dice:
El modo estricto afecta si el servidor permite ‘0000-00-00’ como fecha válida: si el modo estricto no está habilitado, se permite ‘0000-00-00’ y las inserciones no producen ninguna advertencia. Si el modo estricto está habilitado, ‘0000-00-00’ no está permitido y las inserciones producen un error, a menos que también se proporcione IGNORE. Para INSERT IGNORE y UPDATE IGNORE, se permite ‘0000-00-00’ y las inserciones producen una advertencia.
Para comprobar el modo MYSQL
SELECT @@GLOBAL.sql_mode global, @@SESSION.sql_mode session
Inhabilitando el modo STRICT_TRANS_TABLES
Sin embargo, para permitir el formato 0000-00-00 00:00:00tienes que deshabilitar el modo STRICT_TRANS_TABLES en el archivo de configuración mysql o por comando
Por orden
SET sql_mode="";
o
SET GLOBAL sql_mode="";
Usando la palabra clave GLOBAL requiere súper previliges y afecta las operaciones que todos los clientes se conectan a partir de ese momento
si lo anterior no funciona, vaya a /etc/mysql/my.cnf (según ubuntu) y comentar STRICT_TRANS_TABLES
Además, si desea establecer permanentemente el modo SQL al iniciar el servidor, incluya SET sql_mode="" en my.cnf en Linux o MacOS. Para Windows, esto debe hacerse en my.ini expediente.
Nota
Sin embargo, el modo estricto no está habilitado de forma predeterminada en MYSQL 5.6. Por lo tanto, no produce el error según la documentación de MYSQL 6 que dice
MySQL le permite almacenar un valor “cero” de ‘0000-00-00’ como una “fecha ficticia”. En algunos casos, esto es más conveniente que usar valores NULL y usa menos datos y espacio de índice. Para no permitir ‘0000-00-00’, habilite el modo SQL NO_ZERO_DATE.
ACTUALIZAR
Con respecto al asunto del error como lo dijo @ Dylan-Su:
No creo que este sea el problema, es la forma en que MYSQL evoluciona a lo largo del tiempo debido a que algunas cosas se cambian en función de la mejora adicional del producto.
Sin embargo, tengo otro informe de error relacionado con el NOW() función
El campo de fecha y hora no acepta el valor predeterminado AHORA ()
Otra nota útil [see Automatic Initialization and Updating for TIMESTAMP and DATETIME]
A partir de MySQL 5.6.5, las columnas TIMESTAMP y DATETIME se pueden inicializar y actualizar automáticamente a la fecha y hora actuales (es decir, la marca de tiempo actual). Antes de 5.6.5, esto es cierto solo para TIMESTAMP, y como máximo para una columna TIMESTAMP por tabla. Las siguientes notas describen primero la inicialización y actualización automática para MySQL 5.6.5 y posteriores, luego las diferencias para las versiones anteriores a 5.6.5.
Actualización sobre NO_ZERO_DATE
A partir de MySQL a partir de 5.7.4, este modo está obsoleto. Para la versión anterior, debe comentar la línea respectiva en el archivo de configuración. Consulte la documentación de MySQL 5.7 el NO_ZERO_DATE
Tuve este error con WAMP 3.0.6 con MySql 5.7.14.
Solución:
cambie la línea 70 (si su archivo ini está intacto) en c:wampbinmysqlmysql5.7.14my.ini archivo de
sql-mode= "STRICT_ALL_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ZERO_DATE,NO_ZERO_IN_DATE,NO_AUTO_CREATE_USER"
para
sql-mode="ERROR_FOR_DIVISION_BY_ZERO,NO_ZERO_DATE,NO_ZERO_IN_DATE,NO_AUTO_CREATE_USER"
y reinicie todos los servicios.
Esto desactivará el modo estricto. Según la documentación, “modo estricto” significa un modo con uno o ambos STRICT_TRANS_TABLES o STRICT_ALL_TABLES activado. La documentación dice:
“El modo SQL predeterminado en MySQL 5.7 incluye estos modos: ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER y NO_ENTITUTION_SUBSUBS.”
Entré en una situación en la que los datos se mezclaban entre NULL y 0000-00-00 para un campo de fecha. Pero no sabía cómo actualizar el ‘0000-00-00’ a NULL, porque
update my_table set my_date_field=NULL where my_date_field='0000-00-00'
ya no está permitido. Mi solución fue bastante simple:
update my_table set my_date_field=NULL where my_date_field<'1000-01-01'
porque todo lo incorrecto my_date_field los valores (sean fechas correctas o no) eran anteriores a esta fecha.