https://dev.mysql.com/doc/refman/8.0/en/datetime.html
datetime和timestamp在mysql内部的存储方式不同,且理论上timestamp类型的数据在数据库时区变更后依然能正确读取到存入时的数值;
但是,在数据库本地提取数据时,已正确完成转换的时间数据,经过jdbc协议传输到远程客户端后,还是有可能被错误处理。
CREATE TABLE `test_datetime` (
`id` bigint(21) NOT NULL AUTO_INCREMENT COMMENT '流水号',
`create_by` varchar(32) DEFAULT NULL COMMENT '创建人',
`create_time` timestamp(3) DEFAULT CURRENT_TIMESTAMP(3) COMMENT '创建时间',
`modify_time` datetime(3) DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3) COMMENT '修改时间(每次更新都记录)',
PRIMARY KEY (`id`),
UNIQUE KEY `index_create_by` (`create_by`))
ENGINE = InnoDB CHARSET = utf8mb4 COMMENT '验证';
MySQL将来自操作系统的CST时区识别为中国标准时间;
jdbc客户端8.0.22及以下版本,虽然会主动获取数据库的时区配置,但会将CST认为是美国中部时间,这就导致反序列化后的Date与实际时间会相差13小时,如果处在冬令时还会相差14个小时;
因为在数据库进程正确从本地文件块里解析后的datetime、timestamp数据,在通过jdbc协议传输前,会使用数据库默认时区进行序列化(序列化结果不含时区信息),被jdbc客户端接收后再使用美国中部时区进行反序列化,于是得到一个错误的java.util.Date。
mysql-connector-java的8.0.23版本开始对CST时区进行了解析修复,对应到了Asia/Shanghai。
jdbc的url参数里,明确指定数据库服务器实际时区后,可避免jdbc序列化反序列化时间数据的异常
?serverTimezone=GMT%2B8&useSSL=false&characterEncoding=UTF-8&zeroDateTimeBehavior=convertToNull
通过jdbc能否获取到正确的Date数据,和java进程本身的时区没有联系,通过修改java进程默认时区即可验证这点:-Duser.timezone=GMT+9
UNIX认为GMT时区的1970年1月1日零点是时间纪元起始;
大多数语言/系统的时间戳就是相对上述时间点的毫秒数,使用long类型记录和传输
java的Date类型内部实际使用数字时间戳(long类型)进行记录,可认为Date与进程、服务器时区无关;java.sql.Timestamp继承自Date,扩展了对纳秒信息的记录。
json反序列化时(把json格式的字符串转换为内部对象),各框架(jackson、fastjson)都能自动把数字字段转换到java的Date字段;json序列化时,各框架(jackson、fastjson)都默认是把Date字段序列化为数字时间戳。
java和javascript的Date构造函数,都可用数字时间戳作为初始化参数;java和javascript的Date都有getTime方法来获取内部存储的数字时间戳。
浏览器端提交的数据字段,在服务端是时间类型时,在浏览器端提交数字时间戳即可自动正确转换,即使两端时区不一致。
// 解析
OffsetDateTime dateTime = OffsetDateTime.parse("1997-07-16T19:20:30.010+01:00");
// 序列化(线程不安全),默认使用进程时区,可以另外指定
SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSXXX");
log.info(format.format(Date.from(dateTime.toInstant())));
controller层返回结果时,springboot使用的jackson默认把Date字段序列化为ISO8601字符串,可通过配置项修改为数字时间戳:
spring.jackson.serialization.write-dates-as-timestamps=true
建议前端先转化为Date数据类型后,再根据浏览器本地时区展示为可阅读的字符串
// Date的构造函数既可传入时间戳数值,又可传入ISO8601字符串
new Date('1997-07-16T19:20:30+01:00');
// Date实例的toJSON、toISOString方法都能获取到ISO8601格式字符串
// JSON.stringify方法处理Date类型的字段时,就是用toJSON进行序列化
(new Date()).toJSON();
(new Date()).toISOString();
在浏览器端用JSON.stringify处理js对象的Date字段后(ISO8601序列化)再传输,即使两端时区不一致,服务端也能正确解析到java的Date字段。
java服务端、sql里尽量避免直接处理不含时区信息的时间字符串;
无法避免时,每个功能点需要慎重确认是不是适合使用服务端java程序的启动时区,是否应该要求客户端指定时区。
如果时区信息包含夏令时/冬令时处理规范,则解析不含时区信息的时间字符串时,会进行偏移处理;比如下面的例子,"GMT+8"时区不进行时间偏移,"Asia/Shanghai"时区进行时间偏移
SimpleDateFormat isoFormat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSXXX");
isoFormat.setTimeZone(TimeZone.getTimeZone("GMT+8"));
String strDate = "1989-05-31 08:00:00"; //不含时区信息
SimpleDateFormat gmt8Format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
gmt8Format.setTimeZone(TimeZone.getTimeZone("GMT+8"));
SimpleDateFormat shanghaiFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
shanghaiFormat.setTimeZone(TimeZone.getTimeZone("Asia/Shanghai"));
log.info("不使用中国夏令时:{},使用中国夏令时:{}", isoFormat.format(gmt8Format.parse(strDate)),
isoFormat.format(shanghaiFormat.parse(strDate)));
STR_TO_DATE
DATE_FORMAT
如果在sql执行时进行时间字符串转换,那么结果受当前session的时区信息影响;
而jdbc建立的session,是使用数据库默认时区(不受serverTimezone配置影响),可通过获取select @@SESSION.time_zone的结果进行确认;
如果java应用非要把字符串写入数据表的datetime字段,这个字符串必须表示的是数据库默认时区下的时间点(强烈不推荐)
# 时区是否支持夏令时规范、是否在经度上一致,影响获得的数字时间戳
SET time_zone = 'Asia/Shanghai';
SELECT UNIX_TIMESTAMP(STR_TO_DATE('1989-05-31 08:00:00','%Y-%m-%d %T'));
SET time_zone = '+08:00';
SELECT DATE_FORMAT(NOW(6), '%Y-%m-%d %T.%f');
因为无法指定slave连接master时使用的时区,binlog里序列化的datetime数据无法正确反序列化,所以master、slave的时区配置不一致时,不能正确同步
因为存在中间转换,只要otter连接到两个数据库节点的serverTimezone配置正确,即可正确同步