今天把應用部署到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
