通过这篇文章，澄清以下几个对时间数据进行序列化/反序列化的阶段：
mysql进程从数据块里读取时间字段、把时间字段通过jdbc发送、接收从jdbc读取的时间字段、web服务传输json序列化后的时间字段；
让java开发员确信目前使用的技术栈，实际已经是在正确处理跨时区的时间信息传输

一、jdbc协议对时间的序列化(不含时区信息)

数据库的两个时间类型

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 '验证'; 

中国数据库使用的CST时区无法被java正确识别

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协议跨时区传输方案

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方法来获取内部存储的数字时间戳。

浏览器端提交的数据字段，在服务端是时间类型时，在浏览器端提交数字时间戳即可自动正确转换，即使两端时区不一致。

三、ISO8601(可跨时区传输)

java的序列化方法

// 解析
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数据类型后，再根据浏览器本地时区展示为可阅读的字符串

js的序列化方法

// 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)));

sql函数

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');

五、跨时区binlog同步

master-slave原生同步

因为无法指定slave连接master时使用的时区，binlog里序列化的datetime数据无法正确反序列化，所以master、slave的时区配置不一致时，不能正确同步

otter同步

因为存在中间转换，只要otter连接到两个数据库节点的serverTimezone配置正确，即可正确同步