mysql cst_一次 JDBC 与 MySQL 因 “CST” 时区协商误解导致时间差了 14 或 13 小时的排错经历...

摘要

名为 CST 的时区是一个很混乱的时区,在与 MySQL 协商会话时区时,Java 会误以为是 CST -0500,而非 CST +0800。

CST 时区

名为 CST 的时区是一个很混乱的时区,有四种含义:

美国中部时间 Central Standard Time (USA) UTC-06:00

澳大利亚中部时间 Central Standard Time (Australia) UTC+09:30

中国标准时 China Standard Time UTC+08:00

古巴标准时 Cuba Standard Time UTC-04:00

今天是“4月28日”。为什么提到日期?因为美国从“3月11日”至“11月7日”实行夏令时,美国中部时间改为 UTC-05:00,与 UTC+08:00 相差 13 小时。

排错过程

在项目中,偶然发现数据库中存储的 Timestamp 字段的 unix_timestamp() 值比真实值少了 13 个小时。通过调试追踪,发现了 com.mysql.cj.jdbc 里的时区协商有问题。

当 JDBC 与 MySQL 开始建立连接时,会调用 com.mysql.cj.jdbc.ConnectionImpl.initializePropsFromServer() 获取服务器参数,其中我们看到调用 this.session.configureTimezone() 函数,它负责配置时区。

public void configureTimezone() {

String configuredTimeZoneOnServer = getServerVariable("time_zone");

if ("SYSTEM".equalsIgnoreCase(configuredTimeZoneOnServer)) {

configuredTimeZoneOnServer = getServerVariable("system_time_zone");

}

String canonicalTimezone = getPropertySet().getStringReadableProperty(PropertyDefinitions.PNAME_serverTimezone).getValue();

if (configuredTimeZoneOnServer != null) {

// user can override this with driver properties, so don't detect if that's the case

if (canonicalTimezone == null || StringUtils.isEmptyOrWhitespaceOnly(canonicalTimezone)) {

try {

canonicalTimezone = TimeUtil.getCanonicalTimezone(configuredTimeZoneOnServer, getExceptionInterceptor());

} catch (IllegalArgumentException iae) {

throw ExceptionFactory.createException(WrongArgumentException.class, iae.getMessage(), getExceptionInterceptor());

}

}

}

if (canonicalTimezone != null && canonicalTimezone.length() > 0) {

this.serverTimezoneTZ = TimeZone.getTimeZone(canonicalTimezone);

// The Calendar class has the behavior of mapping unknown timezones to 'GMT' instead of throwing an exception, so we must check for this...

if (!canonicalTimezone.equalsIgnoreCase("GMT")

&& this.serverTimezoneTZ.getID().equals("GMT")) {

throw ...

}

}

this.defaultTimeZone = this.serverTimezoneTZ;

}

追踪代码可知,当 MySQL 的 time_zone 值为 SYSTEM 时,会取 system_time_zone 值作为协调时区。

让我们登录到 MySQL 服务器验证这两个值:

mysql> show variables like '%time_zone%';

+------------------+--------+

| Variable_name | Value |

+------------------+--------+

| system_time_zone | CST |

| time_zone | SYSTEM |

+------------------+--------+

2 rows in set (0.00 sec)

重点在这里!若 String configuredTimeZoneOnServer 得到的是 CST 那么 Java 会误以为这是 CST -0500,因此 TimeZone.getTimeZone(canonicalTimezone) 会给出错误的时区信息。

d29a07cd7f0f64564fe19b5a1e1d5734.pngdebug variables

如图所示,本机默认时区是 Asia/Shanghai +0800,误认为服务器时区为 CST -0500,实际上服务器是 CST +0800。

我们会想到,即便时区有误解,如果 Timestamp 是以 long 表示的时间戳传输,也不会出现问题,下面让我们追踪到 com.mysql.cj.jdbc.PreparedStatement.setTimestamp()。

public void setTimestamp(int parameterIndex, Timestamp x) throws java.sql.SQLException {

synchronized (checkClosed().getConnectionMutex()) {

setTimestampInternal(parameterIndex, x, this.session.getDefaultTimeZone());

}

}

注意到这里 this.session.getDefaultTimeZone() 得到的是刚才那个 CST -0500。

private void setTimestampInternal(int parameterIndex, Timestamp x, TimeZone tz) throws SQLException {

if (x == null) {

setNull(parameterIndex, MysqlType.TIMESTAMP);

} else {

if (!this.sendFractionalSeconds.getValue()) {

x = TimeUtil.truncateFractionalSeconds(x);

}

this.parameterTypes[parameterIndex - 1 + getParameterIndexOffset()] = MysqlType.TIMESTAMP;

if (this.tsdf == null) {

this.tsdf = new SimpleDateFormat("''yyyy-MM-dd HH:mm:ss", Locale.US);

}

this.tsdf.setTimeZone(tz);

StringBuffer buf = new StringBuffer();

buf.append(this.tsdf.format(x));

if (this.session.serverSupportsFracSecs()) {

buf.append('.');

buf.append(TimeUtil.formatNanos(x.getNanos(), true));

}

buf.append('\'');

setInternal(parameterIndex, buf.toString());

}

}

原来 Timestamp 被转换为会话时区的时间字符串了。问题到此已然明晰:

JDBC 误认为会话时区在 CST-5

JBDC 把 Timestamp+0 转为 CST-5 的 String-5

MySQL 认为会话时区在 CST+8,将 String-5 转为 Timestamp-13

最终结果相差 13 个小时!如果处在冬令时还会相差 14 个小时!

解决方案

解决办法也很简单,明确指定 MySQL 数据库的时区,不使用引发误解的 CST:

mysql> set global time_zone = '+08:00';

Query OK, 0 rows affected (0.00 sec)

mysql> set time_zone = '+08:00';

Query OK, 0 rows affected (0.00 sec)

或者修改 my.cnf 文件,在 [mysqld] 节下增加 default-time-zone = '+08:00'。

修改时区操作影响深远,需要重启 MySQL 服务器,建议在维护时间进行。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
提供的源码资源涵盖了安卓应用、小程序、Python应用和Java应用等多个领域,每个领域都包含了丰富的实例和项目。这些源码都是基于各自平台的最新技术和标准编写,确保了在对应环境下能够无缝运行。同时,源码中配备了详细的注释和文档,帮助用户快速理解代码结构和实现逻辑。 适用人群: 这些源码资源特别适合大学生群体。无论你是计算机相关专业的学生,还是对其他领域编程感兴趣的学生,这些资源都能为你提供宝贵的学习和实践机会。通过学习和运行这些源码,你可以掌握各平台开发的基础知识,提升编程能力和项目实战经验。 使用场景及目标: 在学习阶段,你可以利用这些源码资源进行课程实践、课外项目或毕业设计。通过分析和运行源码,你将深入了解各平台开发的技术细节和最佳实践,逐步培养起自己的项目开发和问题解决能力。此外,在求职或创业过程中,具备跨平台开发能力的大学生将更具竞争力。 其他说明: 为了确保源码资源的可运行性和易用性,特别注意了以下几点:首先,每份源码都提供了详细的运行环境和依赖说明,确保用户能够轻松搭建起开发环境;其次,源码中的注释和文档都非常完善,方便用户快速上手和理解代码;最后,我会定期更新这些源码资源,以适应各平台技术的最新发展和市场需求。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值