关于JDK8原生的时间格式化错误分析和正确使用方式

关于JDK8原生的时间格式化错误分析和正确使用方式

问题背景

这是一场由DateTimeParseException: Text '20210601140102123' could not be parsed at index 0引发的悬案。

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

以及应该怎么解决这个问题？

先看测试代码

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);
}

错误信息：

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++) {

        //最大结束小标：第一次是字符长度，这里是17
         //第二次这里是min(7,17)=7
        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~更大）。
上面的栗子中“20210601140102123”子序列是多少？应该是13，但实际却是10，原因请看下面官方解释。

Java官方论坛的讨论

讨论地址：https://bugs.openjdk.java.net/browse/JDK-8031085

大致翻译：相邻值解析通常是一个难题。它意在处理第一个元素是可变宽度（年）而所有其他元素是固定宽度（月、日等）的情况。但是毫秒的“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 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);
}

运行结果如下：

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

 我是Pandas，专注Java实用技术分享，公众号`Java实用技术手册`和B站均有视频解说，欢迎来玩。

 如果你觉得这篇文章有用，别忘了点赞+关注，一起进步！