今天把應用部署到AWS上發現後台修改內容提交後程序報錯，經過排查發現是更新數據的時候，有張數據表中的一個timestamp類型的字段默認值變成了"0000-00-00 00:00:00.000000"格式，導致解析失敗造成的。
在mysql該字段的創建語句如下
`XXX` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP 正常情況下 應該是當前數據更改的時間格式
因為在本地開發環境測試過，沒有該問題，應用環境一直，唯一不同的是，生產環境數據庫用的是AWS的RDS的mysql，經過對錯誤信息的搜索，大致應該是mysql參數配置的問題。
看了下mysql官方文檔
By default, the first TIMESTAMP column has both DEFAULT CURRENT_TIMESTAMP and ON UPDATE CURRENT_TIMESTAMP if neither is specified explicitly。
很多時候，這並不是我們想要的，如何禁用呢？
1. 將“explicit_defaults_for_timestamp”的值設置為ON。
2. “explicit_defaults_for_timestamp”的值依舊是OFF，也有兩種方法可以禁用
1> 用DEFAULT子句該該列指定一個默認值
2> 為該列指定NULL屬性。
mysql> show variables like '%explicit_defaults_for_timestamp%'; +---------------------------------+-------+ | Variable_name | Value | +---------------------------------+-------+ | explicit_defaults_for_timestamp | OFF | +---------------------------------+-------+ row in set (0.00 sec)
開發環境explicit_defaults_for_timestamp 的值是OFF
比對了下RDS中mysql的參數，發現這個參數值為0，因為rds中mysql的默認參數組是不允許修改的，所以創建個參數組，會默認把default的參數組繼承過來，當時並不知道這裡的0和1是怎麼對應on和off的，所以就把值改成了1.然後重啟rds。
此時發現就不會有該錯誤了。
將rds中mysql的參數改成如下情況 完美解決
explicit_defaults_for_timestamp = 1
