@JsonFormat解析6位毫秒日期报错及毫秒段可选配置咨询

6位小数秒格式的解析支持情况 #

分两种场景判断：

• 标记@JsonFormat的字段为旧版java.util.Date类型：不支持。
  解析Date类型时框架底层调用JDK原生SimpleDateFormat，其中模式符S的语义是毫秒数值，而非秒的小数位。配置pattern = "yyyy-MM-dd'T'HH:mm:ss.SSSSSS"时，框架会把小数点后6位数字整体作为毫秒值解析，示例值里的518925远大于单秒最大毫秒值999，必然触发解析报错。
• 标记@JsonFormat的字段为Java 8+ 引入的java.time包时间类型（如LocalDateTime、OffsetDateTime、ZonedDateTime）：支持，需满足两个前提：
  • 项目引入jackson-datatype-jsr310依赖，且Jackson注册了JavaTimeModule（Spring Boot项目默认自动完成该配置，无需手动注册）
  • 此时解析底层使用DateTimeFormatter，模式符S的语义是秒的小数位，配置yyyy-MM-dd'T'HH:mm:ss.SSSSSS即可正常解析6位微秒精度的时间字符串，不会出现数值越界问题。

小数秒部分可选匹配的实现方式 #

原生@JsonFormat的pattern规则不支持[.SSSSSS]这类方括号标记可选段的写法，直接写方括号会被识别为普通字符，无法达到可选匹配效果，可通过以下方式实现需求：

• 针对java.time包的时间类型，无需额外配置可选规则：只要在pattern中写的S位数大于等于业务可能传入的小数秒最大长度（比如写6个S适配最多6位小数秒），DateTimeFormatter解析时会自适应小数秒长度——无论传入的时间字符串不带小数秒、带3位毫秒、还是带6位微秒，都能正常解析，天然兼容可选的小数秒场景。
• 如果需要兼容更复杂的多格式场景（比如不同接口传入的时间格式差异较大），可以自定义Jackson反序列化器，在解析逻辑中实现多格式匹配，再通过@JsonDeserialize注解指定该自定义解析器即可，不受固定pattern的规则限制。

补充建议：如果当前还在使用java.util.Date类型，建议直接迁移到java.time包下的对应时间类，旧Date类本身存在大量API设计缺陷，在时间精度、时区处理上的坑较多，没有必要在旧类型上做额外兼容。

内容的提问来源于stack exchange，提问作者Evillain