EEST时区下MySQL CONVERT_TZ转换UTC时间行为异常咨询
嘿，我之前也踩过MySQL时区转换的类似坑，咱们来一步步拆解你遇到的这个奇怪现象——你说转换1970-01-01 02:00:00（对应Unix时间0的EEST本地时间）到UTC时不符合预期，但前后的时间都正常，这大概率和MySQL时区数据库的边界处理以及EEST时区的标识歧义有关。
先搞懂问题根源
首先，Unix时间0对应的UTC是1970-01-01 00:00:00，你的服务器是EEST（东欧夏令时，UTC+2），所以本地时间确实应该是02:00:00。但这里有两个关键点：
- Unix纪元是时间处理的边界点：很多系统对1970-01-01 00:00:00 UTC这个时刻的处理都有特殊逻辑，MySQL的时区转换也不例外，刚好卡在这个点的时间容易触发异常。
- EEST是夏令时标识，1月不该用它：EEST是东欧夏令时，一般是夏季用的，1月份东欧应该是EET（东欧标准时间，同样UTC+2，但标识不同）。如果你的服务器系统时区直接设成了
EEST而非完整的时区名称（比如Europe/Athens），MySQL在解析这个时区时会出现混淆。
一步步验证和解决
1. 先确认MySQL的时区设置
先跑这两条SQL看看你的时区配置：
SELECT @@system_time_zone, @@session.time_zone;
如果@@system_time_zone显示的是EEST，那问题就出在这儿了——夏令时标识不适合作为系统默认时区，改用具体的地理时区名称（比如Europe/Istanbul、Europe/Bucharest，根据你的实际位置）会靠谱得多。
2. 用明确的时区名称替代SYSTEM
别再用SYSTEM当源时区了，换成具体的时区标识符试试，比如：
-- 假设你的实际时区是Europe/Athens SELECT CONVERT_TZ('1970-01-01 02:00:00', 'Europe/Athens', '+00:00');
MySQL对完整地理时区名称的处理更准确，因为这些名称包含了历史时区变更的完整数据，不会像夏令时缩写那样有歧义。
3. 更新MySQL的时区数据库（如果需要）
要是上面的方法没用，可能是你的MySQL时区数据不全。Linux系统可以用这个命令导入系统的时区数据：
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql
输完密码导入后，重启MySQL服务，再试转换操作。
4. 绕个路：用Unix时间戳转换
如果CONVERT_TZ死活不正常，咱们直接绕过时区函数，用时间戳来转：
-- 先把本地时间转成Unix时间戳，再转回UTC时间 SELECT FROM_UNIXTIME(UNIX_TIMESTAMP('1970-01-01 02:00:00') - TIMESTAMPDIFF(SECOND, NOW(), UTC_TIMESTAMP()));
或者更简单，直接拿Unix时间0转UTC：
SELECT FROM_UNIXTIME(0); -- 直接得到'1970-01-01 00:00:00'
为啥前后的时间转换正常？
你测试的1970-01-01 02:00:01和1970-01-01 04:00:00都在Unix纪元之后，MySQL的时区转换逻辑处理这些非边界时刻时，能正确匹配时区偏移；而1970-01-01 02:00:00刚好卡在Unix纪元对应的本地时间点，触发了MySQL时区库的特殊边界处理，才出现了异常。
内容的提问来源于stack exchange，提问作者andreas
