MYSQL时区导致时间差了14或13小时的解决方法

目录
  • CST 时区
  • 排错过程
  • 解决方案
  • MySQL时区有问题(相差13或14小时)

p>我一般使用MYSQL定义字段类型时,一般使用TIMESTAMP时间戳来定义创建时间与更新时间,并将其定义为默认值为CURRENT_TIME,但是由于场景特殊,现在我需要将一个任务的开始时间与结束时间记录,并写入数据库,那么我的开始时间戳与结束时间戳则不应该是使用数据库自带的默认值的,而是应该使用我使用java代码里面传进去的LocalDateTime.now()方法。但是插入后数据我发现有问题,插入的时间比我当前的实际时间少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) 会给出错误的时区信息。

debug 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 服务器,建议在维护时间进行。

JSR-310相关规范在这个版本就已经支持了,所以大家只要不小于此版本的就放心用吧。举个例子:

public class User {
    private LocalDateTime createTime;
    // setter ... getter ... 省略了哈
}

public interface UserDao {
    @Insert("INSERT INTO user(create_time) values(#{createTime})")
    int insertUser(User user);
}

// 在set时间时,一般直接用now方法就好
user.setCreateTime(LocalDateTime.now());

这样就OK了,如果你数据库表存的是datetime类型的话,MyBatis自动帮你解析转换,你不用做额外工作。
注意:
这里LocalDateTime默认是不包含时区信息的,会取当前机器时间的时区,其实一般情况下,是没有问题的,我用阿里云的服务器(在深圳),直接打印出来就是:

System.out.println(LocalDateTime.now());
// 输出的是北京时间
2019-03-15T16:51:37.121

当然这样可能你不是很放心,那么就指明时区:

System.out.println(LocalDateTime.now(ZoneId.of("+08:00")));

MySQL时区有问题(相差13或14小时)

这个问题最开始让我非常头疼,明明我的Tomcat和MySQL在同一个服务器上,Java代码打印时间出来都是对的,结果一插入数据库时间就错了。
然后进入数据库查看时间和时区:

mysql> select curtime();
mysql> show variables like '%time_zone%';

发现时间也没问题,都是北京时间,那为什么通过JDBC一插就差那么十几个小时呢?
问题的原因在这里:一次 JDBC 与 MySQL 因 “CST” 时区协商误解导致时间差了 14 或 13 小时的排错经历
解决办法:
手动修改MySQL的时区,明确指定:

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

或者修改my.cnf配置文件,一劳永逸,添加:

[mysqld]
default-time-zone = '+08:00'

即可,最后记得重启MySQL服务,最好还能重启一下Tomcat。

到此这篇关于MYSQL时区导致时间差了14或13小时的解决方法的文章就介绍到这了,更多相关MYSQL差14或13小时内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 解决MySQL时区日期时差8个小时的问题

    目录 场景: 解决: mysql查出时间相差14小时 问题重现 问题排查 场景: 我们在mysql客户端查询 now() 系统当前日期时间,会发现得到的结果比系统实际日期时间慢8个小时左右,这是由于不同的时区导致的 解决: 1.在 mysql 的服务端的 my.conf 文件中 [mysqld] 节点下设置时区参数 default-time-zone=Asia/Shanghai 2.如果 mysql 的版本是 5.7 配置如下参数 default-time-zone = '+8:00' 3.如果

  • MySQL插入时间差八小时问题的解决方法

    解决MySQL插入时间差八小时问题 一般 jdbc url中 需要添加几个参数 , 大多数博客给的教程都是 useSSL=false&useUnicode=true&characterEncoding=UTF-8&serverTimezone=UTC 这几个参数, 配置结果为:  jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=UTF-8&serverTimezone=UTC 对于

  • mysql查询每小时数据和上小时数据的差值实现思路详解

    一.前言 需求是获取某个时间范围内每小时数据和上小时数据的差值以及比率.本来以为会是一个很简单的sql,结果思考两分钟发现并不简单,网上也没找到参考的方案,那就只能自己慢慢分析了. 刚开始没思路,就去问DBA同学,结果DBA说他不会,让我写php脚本去计算,,这就有点过分了,我只是想临时查个数据,就不信直接用sql查不出来,行叭,咱们边走边试. 博主这里用的是笨方法实现的,各位大佬要是有更简单的方式,请不吝赐教,评论区等你! mysql版本: mysql> select version(); +

  • MySQL总是差八个小时该如何解决

    目录 前言 1. MySQL 本身问题 2. JDBC 连接问题 3. 题外话 4. 小结 前言 今天来聊一个简单的话题,这是一个小伙伴在微信上问我的,对于初学者我非常能理解这类问题带来的困扰,各种尝试,各种搜索,别人说的头头是道,但是就是解决不了自己的问题,今天我简单从两个方面来和大家聊聊这个问题,如果小伙伴们有其他的解决思路,也可以留言一起分享. 这个问题我们可以从两方面来分析: MySQL 本身的问题. Java 代码的问题. 1. MySQL 本身问题 MySQL 本身问题,这个其实很好

  • MySQL5.7慢查询日志时间与系统时间差8小时原因详解

    在对慢查询进行查看的时候发现时间不对,正好与系统时间相差8个小时. 1.慢查询显示时间如下 # Time: 2020-01-10T06:42:24.940811Z 2.系统时间 $ date Fri Jan 10 14:42:31 CST 2020 3.查看数据库参数 mysql> show variables like 'log_timestamps'; +----------------+-------+ | Variable_name | Value | +----------------

  • MYSQL时区导致时间差了14或13小时的解决方法

    目录 CST 时区 排错过程 解决方案 MySQL时区有问题(相差13或14小时) p>我一般使用MYSQL定义字段类型时,一般使用TIMESTAMP时间戳来定义创建时间与更新时间,并将其定义为默认值为CURRENT_TIME,但是由于场景特殊,现在我需要将一个任务的开始时间与结束时间记录,并写入数据库,那么我的开始时间戳与结束时间戳则不应该是使用数据库自带的默认值的,而是应该使用我使用java代码里面传进去的LocalDateTime.now()方法.但是插入后数据我发现有问题,插入的时间比我

  • mysql 5.7更改数据库的数据存储位置的解决方法

    随着MySQL数据库存储的数据逐渐变大,已经将原来的存储数据的空间占满了,导致mysql已经链接不上了.因此,必须要给存放的数据换个地方了.下面是操作过程中的一些步骤.记下来,以后日后查看. 1.修改mysql数据存放的目录 要修改两个地方,其一是修改/etc/my.cnf文件中的datadir.默认情况下: datadir=/var/lib/mysql 因为我的/data/目录比较大,所以将其改为: datadir=/data/mysql/ 还要修改/etc/init.d/mysqld文件,将

  • MySQL数据中很多换行符和回车符的解决方法

    发现问题 今天一大早客户给我打电话:"小陈儿,昨晚我往数据库导了几十万条数据,然后在web界面很多都搜不到,你们系统做的啥玩意儿啊?这么多BUG!得啵得啵得-"(省略2000字)又习惯性的喷了一遍我们这个项目做的辣鸡~~ 得得得,客户随便喷,我就当吃了个早饭了

  • Mysql挂掉后无法重启报pid文件丢失的解决方法

    阿里云单核2G的配置挂着两个企业网站,访问量一般.最近每天几乎都会出现网站打不开显示数据库链接失败的问题. 多方寻求原因发现,mysql的pid文件缺失,并无法重启自建,后来也看了其他帖子说关闭日志什么的未果,查看系统日志发现,是因为内存满了导致mysql进程被杀,然后就一直挂起状态. Sep 25 11:33:48 iZ28jcqqr7lZ kernel: Out of memory: Kill process 23201 (mysqld) score 53 or sacrifice chil

  • MySQL的自增ID(主键) 用完了的解决方法

    在 MySQL 中用很多类型的自增 ID,每个自增 ID 都设置了初始值.一般情况下初始值都是从 0 开始,然后按照一定的步长增加(一般是自增 1).一般情况下,我们都是用int(11)来作为数据表的自增 ID,在 MySQL 中只要定义了这个数的字节长度,那么就会有上限. MySQL的自增ID(主键) 用完了,怎么办? 如果用 int unsigned (int,4个字节 ), 我们可以算下最大当前声明的自增ID最大是多少,由于这里定义的是 int unsigned,所以最大可以达到2的32幂

  • mysql启动失败之mysql服务无法启动(服务没有报告任何错误)的解决方法

    目录 错误提示 尝试以下步骤,最终解决问题: 总结 错误提示 My SQL server8.0 安装后,启动失败,提示信息如下: 尝试以下步骤,最终解决问题: 1 查看host文件(C:\Windows\System32\drivers\etc\hosts),是否修改过本地域名,如果将localhost对应的地址修改过,有可能会导致连接mysql server失败. 解决方法:将localhost映射的地址注释掉 2 如果在mysql的安装路径(C:\Program Files\MySQL\My

  • MySQL主键自增会遇到的坑及解决方法

    目录 1. 为什么不用 UUID 2. 主键自增的问题 2.1 数据插入的三种形式 2.2 innodb_autoinc_lock_mode 2.3 实践 3. 小结 在上篇文章中,松哥和小伙伴们分享了 MySQL 的聚簇索引,也顺便和小伙伴们分析了为什么在 MySQL 中主键不应该使用随机字符串.但是主键不用随机字符串用什么?主键自增?主键自增就是最佳方案吗?有没有其他坑?今天我们就来讨论下这个话题. 1. 为什么不用 UUID 经过上篇文章的介绍,我们知道在 MySQL 中,主键索引就是聚簇

  • mysql登录报错提示:ERROR 1045 (28000)的解决方法

    本文分析了mysql登录报错提示:ERROR 1045 (28000)的解决方法.分享给大家供大家参考,具体如下: 一.问题: 公司linux系统的mysql数据库root用户设置过密码,但常常用命令'mysql -u root -p'登录报错,有时又能登录.登录报错信息为: [root@localhost ~]# mysql -u root -p Enter password: ERROR 1045 (28000): Access denied for user 'root'@'localho

  • Mysql 报Row size too large 65535 的原因及解决方法

    报错信息:Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535 向mysql的表插件一个字段 类型为text时,或修改一个字段类型为text时,报出上面的错误.其实我对这个错误的原因理解也不是很深,给出一些我查到的解释吧 大意是数据表中有一个设定长度为64K的字段索引,当表中字段(不知道是字段名字还是什么)不能超过这个长度,65,535所说明的是针对的是整个表的

  • MySQL常见错误有哪些_MySQL常见错误的快速解决方法

    1. TokuFT file system space is really low and access is restricted 解决方法:修改tokudb_fs_reserve_percent参数,不过该参数是静止参数,需重启实例 2. 以上这篇MySQL常见错误有哪些_MySQL常见错误的快速解决方法就是小编分享给大家的全部内容了,希望能给大家一个参考,也希望大家多多支持我们.

随机推荐