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是字符长度，这里是17
		int 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 width
			int parseLen = pos - position; // 第一次这里是17
			// 这里effMaxWidth=max(4,17-10)=7
			effMaxWidth = 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=7
		int parseLen = pos - position; 
		if (positive) {  // 没有正负符号处理，不走这里
			if (parseLen <= minWidth) {
				return ~(position - 1);  // '+' only parsed if minWidth exceeded
			}
		} else { //进入这个分支，minWidth=4
			if (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);
    }
}

以上就是本期全部内容，如果你的项目中使用JDK1.8中，碰到了这个问题，希望可以对你有帮助。

文章首发于公众号：关于JDK8时间格式化错误分析和正确使用姿势

转载请联系获得授权，侵权必究。

码字不易，欢迎一键三连