在springboot中开发RESTful接口,经常会遇到日期时间转换相关的问题,例如我们明明输入看起来很正常的日期时间字符串,但是系统却报错无法解析:
JSON parse error: Cannot deserialize value of type java.time.OffsetDateTime from String “2020-06-06 14:26:31”
或者接口返回的日期时间字符串是一个很奇怪的字符串:
2020-06-04 14:41:54.767135400+08:00
如何正确的处理日期时间,本文将一探究竟。
日期时间格式标准
有两个标准组织对日期时间格式进行规范,一个是IETF,一个是ISO。虽然IETF的定义更早,但是它存在一些问题,ISO的定义使用更普遍。但是不管哪种定义,我们常常使用的yyyy-MM-dd HH:mm:ss这种格式都不是标准的,你是否非常惊讶呢。
IETF
RFC822->RFC2822->RFC5322
日期时间的本文表示最早是在电子邮件消息中被讨论和定义,可以追溯到Internet刚诞生之时,ARPANET使用的文本信息格式中所定义,也就是RFC822,发布于1982年。此后经过若干次修订,定型是RFC2822,最新版是RFC5322。
通过几个例子来了解下这种格式长什么样子。
最常见的样子如下,通过linux命令date可以打印:
date –rfc-email
Thu, 04 Jun 2020 13:54:52 +0800
有些格式已经不建议使用,RFC2822定义为过时的格式,如:
- 年份使用4位以下数字
- 时区使用时区名,如UT,GMT
RFC1123
RFC1123并不定义日期时间格式,而是描述应用程序之间通信协议的需求,包括各种应用层协议,如TELNET,FTP,SMTP等,涉及到日期时间格式的正是SMTP,它引用了RFC822,并说明了年份修改为2到4个数字,建议时区总
是使用数字。
RFC1036
同样RFC1306也不定义日期时间格式,而是描述USENET中对日期时间的要求,同样引用了RFC822。
综上IETF的时间格式主要为电子邮件定义,但是只要以可读文本方式表示时间都可以使用。IETF的定义带有明显的时代和地区特征,并不具有国际通用性,也不便于阅读和解析,因此又出现了ISO的日期时间格式。
ISO8601,RFC3339
ISO的日期时间格式有助于避免由许多不同的国家符号引起的国际通信混乱,并提高了计算机用户界面的可移植性。第一版发布于1988年。
RFC3339是ISO8601的概要版本。
先通过例子了解一下他们长什么样子。
date –iso-8601=ns
2020-06-04T14:41:54,767135400+08:00
date –rfc-3339=ns
2020-06-04 14:41:54.767135400+08:00
以上是最常见的样子,ISO8601相对于RFC5322有几个主要变化:
- 多了秒的小数部分,用.或,连接
- 精度上可以从年到秒的小数部分都可以,例如2020、2020-06、2020-06-04都是合法的
- 日期和时间之间增加了连接字符T
- 可以表示一年的第几周的星期几,例如2020-W01-1表示2020年第一周的星期一
- UTC时区可以简写为Z
- 年月日或时分秒之间的连接符可省略
RFC3339和ISO8601的区别:
- RFC3339允许将日期和时间之间的连接符T换为空格
- 秒的小数部分通常使用.连接
- 未使用一年的第几周的星期几的表示
Java日期时间编程接口
Java的发展过程中出现过几个不同的日期时间编程接口。java8之前的日期时间接口存在众所周知的问题,这时只能寻求第三方库库来解决,这就是joda,java8大量借鉴了joda,推出了新的日期时间库。自此,java8日期时间接口成为首选。