Question

Json转换中Date那点事

Answer 1

Java Bean传递过程中Date的格式化过程中时区的处理是一件非常恼人的事情。相信碰到过相关问题的同学应该深有体会。笔者最近也是频频采坑，终于略有收获虽然未能大彻大悟但对付平时开发应该绰绰有余，感兴趣的同学可以持续关注后面进展会持续更新。

首先进入正题前要说明两点，一个是时区的出现只是为了适应不同的地区的本地化时间展示应运而生的他不应该改变绝对的时间，再一个是new Date产生的长整数是一个从 格林威治时间（0时区）1970年1月1日 起的毫秒数的时间戳。换句话说全世界的程序员同时new Date（）得到的这个时间戳应该是一致的，这个就是我所谓的一个绝对时间。我们看到的北京时间上午八点也好，伦敦时间凌晨0点也好只是把这个绝对时间换算成当地时间得到的一个展示形式。

JSON的Date传递过程中通常有两种方式一种是直接传递Date的13位长的时间戳，一种是传递格式化后的类似2019-05-06 11:31:13.708型的字符串。两种方式各有优劣吧，其中传递格式化后的字符串比较直观但是需要处理时区问题，传递时间戳不太直观但是不需要处理时区问题。

假如要传递格式化后的字符串通常需要在序列化的属性上加上@JsonFormat(timezone ="UTC", pattern ="yyyy-MM-dd HH:mm:ss.S")的注解，在序列化过程中表示需要将date 格式化为UTC时区的yyyy-MM-dd HH:mm:ss.S形式，在反序列化中JackJson会将收到的yyyy-MM-dd HH:mm:ss.S字符串理解为UTC时区的时间串这会对最终反序列化后的date时间有直接影响。

如果序列化和反序列化的时区不一致，可以再getter和setter上设置不同的时区表示避免因时区不同造成偏差。

如果可以的话最好传递字符串，可以避免处理时区问题。如果必须传递格式化后的时间表示，最好在最后一层的服务处理。