SpringBoot中使用@DateTimeFormat解析不同时区LocalDateTime出现的异常

• @DateTimeFormat 中使用的z 占位符遵循Java时间格式化的固定规则：仅能匹配带名称的时区、或者整小时精度的UTC偏移量，遇到带分钟的偏移（比如示例中IST时区的+05:30）时，会错误识别偏移前的+号为空白分隔符，最终把入参串拆解为2021-03-02T10:57:43 和 05:30 两部分，和异常日志中“值[2021-03-02T10:57:43 05:30]”的报错表现完全一致。
• 入参类型与传入参数的语义不匹配：LocalDateTime本身是不带时区属性的本地时间类型，不具备承接带时区偏移的时间值的能力，就算解析逻辑兼容了带分钟的偏移，时区信息也会被直接丢弃，容易引发后续业务的隐性时区计算bug。

• 替换时间格式匹配规则：把原注解中用于时区匹配的z 占位符，替换为专门匹配ISO 8601格式UTC偏移的XXX 占位符，可兼容所有带小时、分钟精度的偏移格式，-05:00、+05:30 这类格式均可正常解析。
• 替换入参类型：把原入参的LocalDateTime 类型，替换为OffsetDateTime类型，该类型可完整保留时间值和对应的时区偏移信息，和传入的带偏移的时间串语义完全匹配。

修改后的核心代码：

@GetMapping("/test/datetime/{id}")
public String testDateParsing(@PathVariable String id,
                              @RequestParam("since") @DateTimeFormat(pattern = "yyyy-MM-dd'T'HH:mm:ssXXX") OffsetDateTime since) {
    System.out.println("id : " + id);
    System.out.println("since : " + since);
    return "success";
}

• 之前EST时区的整小时偏移可以正常解析，是因为时间格式化组件对整小时偏移做了历史兼容逻辑，不属于z 占位符的标准匹配能力，一旦遇到非整小时偏移（比如尼泊尔时间的+05:45）就会触发解析失败。
• 如果业务场景确实只需要获取不带时区的本地时间值，可以在解析得到OffsetDateTime后，手动转换为业务指定时区下的LocalDateTime值，不要直接用LocalDateTime承接带时区的时间串。

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