Invalid default value when trying to modify a different column
What versions?  There have been several changes, some incompatible, regarding DATE and other temporal types.  This one jumps out:


  ----- 2013-09-21 5.7.2 Milestone 12 &amp; 2013-07-31 5.6.13 -- Bugs Fixed -- Incompatible Change -----
  
  It is possible for a column DEFAULT value to be valid for the sql_mode
  (
  http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_sql_mode
  ) value at table-creation time but invalid for the sql_mode (
  http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_sql_mode
  ) value when rows are inserted or updated. Example:
  
  SET sql_mode = ''; CREATE TABLE t (d DATE DEFAULT 0); SET sql_mode =
  'NO_ZERO_DATE,STRICT_ALL_TABLES'; INSERT INTO t (d) VALUES(DEFAULT);
  
  In this case, 0 should be accepted for the CREATE TABLE (
  http://dev.mysql.com/doc/refman/5.7/en/create-table.html ) but
  rejected for the INSERT (
  http://dev.mysql.com/doc/refman/5.7/en/insert.html ). However, the
  server did not evaluate DEFAULT values used for inserts or updates
  against the current sql_mode. In the example, the INSERT (
  http://dev.mysql.com/doc/refman/5.7/en/insert.html ) succeeds and
  inserts '0000-00-00' into the DATE (
  http://dev.mysql.com/doc/refman/5.7/en/datetime.html ) column.
  
  The server now applies the proper sql_mode (
  http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_sql_mode
  ) checks to generate a warning or error at insert or update time.
  
  A resulting incompatibility for replication if you use statement-based
  logging (binlog_format=STATEMENT (
  http://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html#sysvar_binlog_format
  )) is that if a slave is upgraded, a nonupgraded master will execute
  the preceding example without error, whereas the INSERT (
  http://dev.mysql.com/doc/refman/5.7/en/insert.html ) will fail on the
  slave and replication will stop.
  
  To deal with this, stop all new statements on the master and wait
  until the slaves catch up. Then upgrade the slaves followed by the
  master. Alternatively, if you cannot stop new statements, temporarily
  change to row-based logging on the master (binlog_format=ROW (
  http://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html#sysvar_binlog_format
  )) and wait until all slaves have processed all binary logs produced
  up to the point of this change. Then upgrade the slaves followed by
  the master and change the master back to statement-based logging.
  (Bug #68041, Bug #16078943)