JDK8时间格式化错误分析和正确使用：DateTimeParseException:Text ‘x‘ could not be parsed at inde 0

本文主要是介绍JDK8时间格式化错误分析和正确使用：DateTimeParseException:Text ‘x‘ could not be parsed at inde 0，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

微信公众号：Java实用技术手册
关注可了解更多java技能和互联网面试技巧。问题或建议，请公众号留言。
如果你觉得这篇文章对你有帮助，欢迎一键三连

问题背景

一场DateTimeParseException: Text '20210601140102123' could not be parsed at index 0引发的学案。

深入分析JDK8的时间格式化DateTimeFormatter为什么不支持这种类型毫秒？

应该怎么解决这个问题？

先看测试代码

public class TestDate {public static void main(String[] args) {DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyyMMddHHmmssSSS");LocalDateTime datetime = LocalDateTime.parse("20210601140102123", formatter); //这里报错System.out.println(datetime);String formatTime = datetime.format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss.SSS"));System.out.println(formatTime);}
}

错误信息：

Exception in thread "main" java.time.format.DateTimeParseException: 
Text '20210601140102123' could not be parsed at index 0    
at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949)    
at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851)    
at java.time.LocalDateTime.parse(LocalDateTime.java:492)    
at com.example.demo.TestDate.main(TestDate.java:16)

CSDN上有一位同学写了类似的问题（使用英文的Nov报错，使用11月就可以解析），但是他的问题，并不是由于JDK8的bug导致，是他自己没有设置Locale导致。

分析过程中他提到了java官方论坛中的issue，该issue回复中讨论了使用三位毫秒不能正常解析的异常原因：

由于JDK8官方代码问题，导致解析器不能正确判断毫秒长度而异常，此问题将会在JDK9修复（实际上JDK9已经修复）

。后面我们先分析源码，再贴出论坛的讨论。

下面我们跟踪源码分析下这个问题根因。

源码跟踪

通过报错的位置得知LocalDateTime.parse()解析报错，我们可以跟踪到如下图的位置：DateTimeFormatterBuilder.CompositePrinterParser#parse，记住这里的subsequentWidth值是10

然后进入了DateTimeFormatterBuilder.NumberPrinterParser#parse方法，核心代码如下：

public int parse(DateTimeParseContext context, CharSequence text, int position) {// 省略其他...int effMaxWidth = (context.isStrict() || isFixedWidth(context) ? maxWidth : 9) + Math.max(subsequentWidth, 0);//总字符累加结果long total = 0;BigInteger totalBig = null;int pos = position;//循环2次，为了解析出年份for (int pass = 0; pass < 2; pass++) {//最后index是字符长度，这里是17int maxEndPos = Math.min(pos + effMaxWidth, length);// 循环对每个字符解析成数字while (pos < maxEndPos) {char ch = text.charAt(pos++);int digit = context.getDecimalStyle().convertToDigit(ch);if (digit < 0) { //有非数字就会走到这里，此次不会pos--;if (pos < minEndPos) {return ~position;  // need at least min width digits}break;}if ((pos - position) > 18) {if (totalBig == null) {totalBig = BigInteger.valueOf(total);}totalBig = totalBig.multiply(BigInteger.TEN).add(BigInteger.valueOf(digit));} else {// 第二次这个total=2021060，很明显这个年份是错误的total = total * 10 + digit; }}if (subsequentWidth > 0 && pass == 0) {// re-parse now we know the correct widthint parseLen = pos - position; // 第一次这里是17// 这里effMaxWidth=max(4,17-10)=7effMaxWidth = Math.max(effMinWidth, parseLen - subsequentWidth);pos = position;total = 0;totalBig = null;} else {break;}}if (negative) { // 不走这里} else if (signStyle == SignStyle.EXCEEDS_PAD && context.isStrict()) {// 进入这个分支，pos=7,position=0，所以parseLen=7int parseLen = pos - position; if (positive) {  // 没有正负符号处理，不走这里if (parseLen <= minWidth) {return ~(position - 1);  // '+' only parsed if minWidth exceeded}} else { //进入这个分支，minWidth=4if (parseLen > minWidth) {//【注意】最后在这里返回，position取反码是 -1，外面抛异常return ~position; }}}//正常应该走到这里return setValue(context, total, position, pos);
}

上面方法退出后，进入下图位置：

最后进入我们抛异常的地方

贴1处错误和正确的关键点的对比，注意subsequentWidth值差异。

错误的解析：

正确的解析：

由上面的源码跟踪可以得知错误原因在于subsequentWidth值不正确。那么subsequentWidth代表什么意思？为什么subsequentWidth不对？

在源码中，subsequent解释是非负数字子序列的宽度（0~更大）。

上面的栗子中“2021_0601140102123_”子序列是多少？应该是13，但实际却是10，原因请看下面官方解释。

Java官方论坛的讨论

讨论地址：bugs.openjdk.java.net/browse/JDK-…

大致翻译：相邻值解析通常是一个难题。它意在处理第一个元素是可变宽度（年）而所有其他元素是固定宽度（月、日等）的情况。但是毫秒的“S”模式字母是一个分数，而不是一个值。具体来说，分数可以是可变宽度 - 多于或少于三位数是有可能的。通常情况下，可变宽度年份和可变宽度毫秒同时出现，就无法确定这两个字段中的哪一个是可变的。

实际上源码中对毫秒的定义，就是0~999宽度范围。

/** 
* The milli-of-second. 
* <p> 
* This counts the millisecond within the second, from 0 to 999. 
* This field has the same meaning for all calendar systems. 
* <p>
* /

现在恍然大悟，我们的时间序列中，年份2021和毫秒123其实都是可变的，一般的使用DateTimeFormatter.ofPattern("yyyyMMddHHmmssSSS")方法排除了毫秒，才把固定宽度子序列计算成10，其实年份后的固定宽度子序列是13。

为什么subsequentWidth是这个结果，可以跟踪DateTimeFormatterBuilder#ofPattern方法，对于"S"是当做可变分数处理，而且默认是纳秒字段，而不是毫秒字段。

FractionPrinterParser解析器是不会更新年份的subsequentWidth。

而NumberPrinterParser会更新年份的subsequentWidth。

解决方案

根据上述分析，只要让代码可以明确知道固定子序列宽度是10，毫秒可变序列宽度是3即可。官方提供的方法是单独拼接毫秒并指定宽度。

public class TestDate {public static void main(String[] args) {DateTimeFormatter formatter = new DateTimeFormatterBuilder().appendPattern("yyyyMMddHHmmss").appendValue(ChronoField.MILLI_OF_SECOND, 3).toFormatter();LocalDateTime datetime = LocalDateTime.parse("20210601140102123", formatter);System.out.println(datetime);String formatTime = datetime.format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss.SSS"));System.out.println(formatTime);}
}