你遇到的这个问题其实是夏令时（Daylight Saving Time，DST）切换导致的经典时间解析坑，我来给你拆解一下背后的原因和解决思路：

问题根源：不存在的时间点 #

2025年3月9日凌晨2点左右，美国、加拿大等众多采用夏令时的地区会执行时钟拨快操作：当地时间凌晨2点会直接跳转到3点，也就是说2:00:00到2:59:59这个时间段在当地时区（比如America/New_York）是根本不存在的，属于「无效时间」。

你的测试代码没有显式指定时区，DateUtils会使用JVM默认的本地时区（大概率是某个执行夏令时切换的时区），当你尝试解析这个不存在的时间时，严格模式下的解析器就会抛出异常。

为什么parseDate能工作而parseDateStrictly不行？ #

• parseDateStrictly底层调用parseDateWithLeniency且leniency为false，会严格校验时间的有效性，一旦遇到不存在的时间点直接抛出异常；
• 而parseDate默认是宽松模式（leniency为true），它会自动调整这个无效时间（比如把2:37自动修正为3:37），所以不会报错，但这种「自动修正」可能会导致时间逻辑出现隐性问题。

关于Calendar的areAllFieldsSet为false #

当解析器尝试处理这个不存在的时间时，Calendar类无法正确映射所有时间字段（因为这个时间在当前时区不存在），所以会把areAllFieldsSet标记为false，这是解析失败的内部表现，本质还是时间本身无效导致的。

解决思路 #

给你几个可行的解决方案，根据业务场景选择：

1. 显式指定UTC时区（推荐，无夏令时问题）

如果业务时间是基于UTC的，直接在解析时指定UTC时区（UTC没有夏令时，这个时间点在UTC是完全合法的）：

import java.text.ParseException;
import java.util.Date;
import java.util.TimeZone;
import org.apache.commons.lang3.time.DateUtils;

public class Test11 {
    public static void main(String[] args) {
        String dateString = "2025-03-09T02:37:51.742";
        String pattern = "yyyy-MM-dd'T'HH:mm:ss.SSS";
        
        try {
            // 显式传入UTC时区
            Date date = DateUtils.parseDateStrictly(dateString, TimeZone.getTimeZone("UTC"), new String[]{pattern});
            System.out.println(date);
        } catch (ParseException e) {
            e.printStackTrace();
        }
    }
}

2. 接受宽松模式的自动修正（谨慎使用）

如果业务允许时间被自动调整，可以使用DateUtils.parseDate替代parseDateStrictly，但要注意解析后的时间会被跳转到3点多，需要确认业务逻辑能接受这种调整。

3. 切换到Java 8+的新时间API（推荐长期方案）

旧的Date/CalendarAPI设计缺陷很多，建议升级到Java 8引入的java.time包（JSR-310），它会更清晰地处理无效时间，API也更直观：

import java.time.LocalDateTime;
import java.time.ZoneId;
import java.time.ZonedDateTime;
import java.time.format.DateTimeFormatter;

public class TestZonedDateTime {
    public static void main(String[] args) {
        String dateString = "2025-03-09T02:37:51.742";
        DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSS");
        
        // 解析为UTC时间（无夏令时问题）
        LocalDateTime localDateTime = LocalDateTime.parse(dateString, formatter);
        ZonedDateTime utcDateTime = localDateTime.atZone(ZoneId.of("UTC"));
        System.out.println("UTC时间: " + utcDateTime);

        // 尝试解析为纽约时区的时间（会直接抛出明确的异常）
        try {
            ZonedDateTime nyDateTime = localDateTime.atZone(ZoneId.of("America/New_York"));
            System.out.println("纽约时区时间: " + nyDateTime);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

这段代码会直接抛出java.time.DateTimeException，比旧API的ParseException更明确地提示时间冲突问题。

你提供的测试代码与错误日志 #

测试代码

import java.text.ParseException;
import java.util.Date;

import org.apache.commons.lang3.time.DateUtils;

public class Test11 {

    public static void main(String[] args) {
        String dateString = "2025-03-09T02:37:51.742";
        
        try {
            Date date = DateUtils.parseDateStrictly(dateString,new String[]{
            "yyyy-MM-dd'T'HH:mm:ss.SSS"});
            System.out.println(date);
        } catch (ParseException e) {
            e.printStackTrace();
        }
    }

}

错误日志

Unable to parse the date: 2025-03-09T02:37:51.742
    at org.apache.commons.lang3.time.DateUtils.parseDateWithLeniency(DateUtils.java:391)
    at org.apache.commons.lang3.time.DateUtils.parseDateStrictly(DateUtils.java:333)
    at org.apache.commons.lang3.time.DateUtils.parseDateStrictly(DateUtils.java:311)
    at com.test.Test11.main(Test11.java:17)

失败的时间样本

2025-03-09T02:52:51.261
2025-03-09T02:45:25.032
2025-03-09T02:08:01.013
2025-03-09T02:59:06.913
2025-03-09T02:57:20.466
2025-03-09T02:19:46.928
2025-03-09T02:45:19.957
2025-03-09T02:49:34.463
2025-03-09T02:13:09.896
2025-03-09T02:04:15.99
2025-03-09T02:09:53.982
2025-03-09T02:10:24.47
2025-03-09T02:24:27.696
2025-03-09T02:17:03.064
2025-03-09T02:05:58.489
2025-03-09T02:24:05.871
2025-03-09T02:41:06.302
2025-03-09T02:04:24.478
2025-03-09T02:32:36.959
2025-03-09T02:26:20.384
2025-03-09T02:40:51.959
2025-03-09T02:33:41.93
2025-03-09T02:58:00.669
2025-03-09T02:48:26.187

备注：内容来源于stack exchange，提问作者vv1