3月09日奇怪的Incorrect datetime value
昨天下午前方实施打电话说应用报错，但后来又恢复了，又是莫名奇妙的问题，当时正在陪娃睡觉.....没接到电话，今天早上也忙着其他事情一直没顾得上，另一方面有其他同事也在查这个问题，下午仔细看了应用日志的报错异常：如下
Incorrect datetime value: '2025-03-09 02:25:59.04' for column 'update_time' at row 1
看应用日志当前时间，和产生的update_time（程序里根据new Date()直接生成的）不一致，看着就像是时区的问题，但即便时区有问题，应该插入的时间不对才是，也不应该报时间格式不合法的错误啊，而且实施后来说插入又没问题了，搞的人百思不得其解，网上搜了相关文章，不是说插入的时间格式的问题就是说需要显示指定datetime的精确位数问题（但这个我试了sql都能插入成功），再说实施反馈问题说后来自己又恢复了，而且去年3月也发生过这个错误，这就比较诡异，好像是多事的3月！于是我想起了最近比较火的deepseek找它问一问。 果然没让我失望，这个红框里看上去感觉像那么回事！！那怎么再复现这个问题呢？
搜了下夏令时，居然发现是为了节约资源！
夏令时开始实施时，时钟需要向前调整一小时，即'加一小时'。例如，当本地时间到达凌晨2点时，时钟会被手动或自动调整为3点。这一调整的目的是通过延长傍晚的日照时间来节约能源，同时减少照明和电器的使用需求。
夏令时的调整逻辑
-
时间调整方向
夏令时开始阶段（通常为春季），时钟会增加一小时，即'夏令时开始，少睡一小时'；结束阶段（通常为秋季），时钟会回拨一小时，即恢复标准时间。调整核心是人为对齐自然光照时段与人类活动时间。 -
操作实例说明
以北美地区为例：- 3月第二个周日凌晨2:00调整为3:00（加一小时）
- 11月第一个周日凌晨2:00回拨为1:00（减一小时）
这种双向调整可避免日期混乱，且选择凌晨时段能减少对日常生活的干扰。
手动2点变成了3点，那2点到3点这段时间相当于跳过了，这段时间的日期都会报不合法？
必须保证应用程序和数据库的时区是一致的。
统一数据库和应用程序的时区
-
问题：应用程序与数据库时区不一致，导致时间转换时产生非法值。
-
验证步骤：
-
检查数据库时区：
SELECT @@global.time_zone, @@session.time_zone;
- 检查应用程序时区（如 JVM 时区）：
-
指定数据库时区可通过连接的mysql连接指定serverTimezone=Asia/Shanghai