Das kleinere Übel besteht möglicherweise darin, den sitzungsweiten SQL-Modus sowohl für das Migrationsskript als auch für die betroffene Anwendung zu ändern – das sollte eine einfache einmalige Änderung sein (solange der Verbindungscode nicht an hundert Stellen kopiert und eingefügt wird). Der Modus, der ungültige Datumsangaben zulässt, ist ALLOW_INVALID_DATES :
SET @@SESSION.sql_mode = CONCAT_WS(',', @@SESSION.sql_mode, 'ALLOW_INVALID_DATES');
Vollständige Demo :
mysql> CREATE TABLE foo (bar DATE);
Query OK, 0 rows affected (0.03 sec)
mysql> SELECT @@SESSION.sql_mode;
+--------------------------------------------+
| @@SESSION.sql_mode |
+--------------------------------------------+
| STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION |
+--------------------------------------------+
1 row in set (0.00 sec)
mysql> INSERT INTO foo (bar) VALUES ('2019-02-30');
ERROR 1292 (22007): Incorrect date value: '2019-02-30' for column 'bar' at row 1
mysql> SET @@SESSION.sql_mode = CONCAT_WS(',', @@SESSION.sql_mode, 'ALLOW_INVALID_DATES');
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> INSERT INTO foo (bar) VALUES ('2019-02-30');
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM foo;
+------------+
| bar |
+------------+
| 2019-02-30 |
+------------+
1 row in set (0.00 sec)
