Joda-Time 已停止维护，不建议在新项目中配置或使用。 它的官方维护早在 2016 年就结束了，Java 8+ 原生 java.time API（JSR-310）已全面取代它，功能更全、线程安全、设计更合理。强行配置 Joda-Time 只会增加兼容性风险和维护成本。
为什么 DateTime 在 Java 17+ 里编译不过
常见错误现象：java.lang.NoClassDefFoundError: org/joda/time/DateTime 或 IDE 报红找不到类 —— 这不是配置问题，是根本没加依赖，或加了但被模块系统（如 Java 9+ 的 module-info.java）拦截了。
- Java 9+ 默认启用强封装，
sun.*和第三方包（包括 Joda-Time）若未显式opens或requires，反射或类加载可能失败 - Maven 项目若用了
spring-boot-starter-web2.5+，它已移除对 Joda-Time 的默认支持，@DateTimeFormat注解不再识别DateTime - Android（尤其是 AGP 8.0+）默认禁用旧时间 API，Joda-Time 需额外配置
coreLibraryDesugaringEnabled true，且仍不保证所有方法可用
如果必须读旧代码里的 DateTime 怎么办
不是“怎么配”，而是“怎么最小化影响地过渡”。核心思路：只在需要解析/格式化老数据的地方桥接，其余全部切到 java.time。
- 用
DateTime.toInstant().atZone(ZoneId.systemDefault())转成ZonedDateTime，避免直接 newLocalDateTime忽略时区 - 反向转换：用
ZonedDateTime.withZoneSameInstant(ZoneId.of("UTC")).toInstant().toDate()再转回DateTime（仅限测试或胶水层） - 别在 DTO 或数据库字段里继续用
DateTime；JPA 实体字段类型应为OffsetDateTime或Instant，配合@Column(columnDefinition = "TIMESTAMP WITH TIME ZONE")
DateTimeFormatter 和 DateTimeFormatter（java.time）参数差异
名字一样，行为不同。Joda-Time 的 DateTimeFormatter 默认宽松解析（比如 "2023-13-01" 可能被转成下一年 1 月），而 java.time.format.DateTimeFormatter 默认严格，一错就抛 DateTimeParseException。
立即学习“Java免费学习笔记（深入）”；
- Joda-Time 支持
DateTimeFormat.forPattern("yyyy-MM-dd").withOffsetParsed()；java.time对应的是DateTimeFormatter.ofPattern("yyyy-MM-dd").withZone(ZoneId.of("GMT"))，但注意：后者不解析时区偏移，要解析带+0800的字符串得用OffsetDateTime.parse(str, formatter) - Joda-Time 的
ISODateTimeFormat.dateTimeNoMillis()等工具方法，在java.time中对应DateTimeFormatter.ISO_LOCAL_DATE_TIME，但前者输出不含 T，后者含 —— 别直接替换字符串模板 - 时区缩写（如
"CST"）在 Joda-Time 中靠DateTimeZone.forID("CST")，而java.time不支持模糊缩写，必须用ZoneId.of("America/Chicago")或ZoneOffset.ofHours(-6)
真正难的不是怎么把 Joda-Time 跑起来，是怎么让团队停止写新的 DateTime 代码。老项目里藏在工具类、日志格式、配置文件里的 Joda-Time 字符串模式，比依赖本身更难清理。
