Invalid default value when trying to modify a different column Problem: I'm trying to modify my column's datatype from a smaller VARCHAR to a larger one so that I can take in IPv6 addresses as well (my current column only takes a size large enough for IPv4 addresses)

Example:
ALTER TABLE accounts MODIFY COLUMN ip VARCHAR(45)

shoots back an error as  

Invalid default value for 'birthday'  


I'm a bit confused because while I do have a birthday column in my accounts table, why is an error being thrown here about it when I'm not touching it?

SHOW CREATE TABLE accounts
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)