网站自助建站北京百度推广优化公司

昨天下午前方实施打电话说应用报错，但后来又恢复了，又是莫名奇妙的问题，当时正在陪娃睡觉.....没接到电话，今天早上也忙着其他事情一直没顾得上，另一方面有其他同事也在查这个问题，下午仔细看了应用日志的报错异常：如下

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点。这一调整的目的是通过延长傍晚的日照时间来节约能源，同时减少照明和电器的使用需求。

夏令时的调整逻辑

1. ​时间调整方向​
   夏令时开始阶段（通常为春季），时钟会​增加一小时​，即'夏令时开始，少睡一小时'；结束阶段（通常为秋季），时钟会​回拨一小时​，即恢复标准时间。调整核心是人为对齐自然光照时段与人类活动时间。

2. ​操作实例说明​
   以北美地区为例：

   • 3月第二个周日凌晨2:00调整为3:00（加一小时）
   • 11月第一个周日凌晨2:00回拨为1:00（减一小时）
     这种双向调整可避免日期混乱，且选择凌晨时段能减少对日常生活的干扰。

手动2点变成了3点，那2点到3点这段时间相当于跳过了，这段时间的日期都会报不合法？

必须保证应用程序和数据库的时区是一致的。

统一数据库和应用程序的时区

• 问题：应用程序与数据库时区不一致，导致时间转换时产生非法值。

• 验证步骤：

  1. 检查数据库时区：

     SELECT @@global.time_zone, @@session.time_zone;

  2. 检查应用程序时区（如 JVM 时区）：

指定数据库时区可通过连接的mysql连接指定serverTimezone=Asia/Shanghai