·  阅读

开发项目过程中经常会出现服务器的时区设置为UTC,而开发机则为GMT+8的情况,这种时候,程序运行就会存在问题,比如数据的插入时间不正确,与旧系统通信时,时间戳转化不正确等等异常情况,排查起来较为费劲,为了解决时区问题,在Java中,jdk8提供了java.time包的LocalDateTime和ZoneDateTime解决方案

LocalDateTime不带有时区信息,而ZoneDateTime带有时区信息

jshell> ZonedDateTime.now()
$6 ==> 2018-08-01T12:51:04.006387+08:00[Asia/Shanghai]
jshell> LocalDateTime.now()
$7 ==> 2018-08-01T12:51:14.459202

在jackson框架对jdk8时间类的补丁:

<dependency>
   <groupId>com.fasterxml.jackson.datatype</groupId>
   <artifactId>jackson-datatype-jsr310</artifactId>
</dependency>

下,LocalDateTime将会被解析成为类似

"2018-08-30T11:20:20"//当服务器的时间为GMT+8时
"2018-08-30T03:20:20"//当服务器的时间为UTC时

而ZoneDateTime将会被解析成为类似

"2018-08-30T11:20:20+08:00" //当服务器的时间为GMT+8时
"2018-08-30T03:20:20Z"//当服务器的时间为UTC时

可以看出,时间在ZoneDateTime类中将会以带有时区信息的格式出现

这种数据在与前端进行交互时,一般使用Date.parse方法,如下所示:

Date.parse('2018-08-30T03:20:20Z')
1535599220000
Date.parse('2018-08-30T11:20:20+08:00')
1535599220000
var a=new Date(1535599220000)
Thu Aug 30 2018 11:20:20 GMT+0800 (中国标准时间)

可以看出来,js直接将时间转换成了本地浏览器时区的时间戳。

对于LocalDateTime来说,显示如下:

Date.parse('2018-08-30 03:20:20')
1535570420000
Date.parse('2018-08-30T03:20:20')
1535570420000
var b=new Date(1535570420000)
Thu Aug 30 2018 03:20:20 GMT+0800 (中国标准时间)

可以看出来,用LocalDateTime方式在前端parse出来,再进行new Date的对象b的时区存在问题,不能再进行时区调整。

所以在此推荐前后端交互时,严格使用带有时区的datetimeString形如

"2018-08-30T03:20:20Z"

即在java中通过ZoneDateTime.now()进行时间相关的处理。

在数据库中,则使用带有时区信息的类型去处理时间,比如在postgreSQL中的timestamptz字段。MySQL中无法做时区处理,推荐使用统一时区:UTC时区,在程序中做相关处理。

如此可以省去部署过程中对机器的时区做调整的步骤。