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-web 2.5+，它已移除对 Joda-Time 的默认支持，@DateTimeFormat 注解不再识别 DateTime
• Android（尤其是 AGP 8.0+）默认禁用旧时间 API，Joda-Time 需额外配置 coreLibraryDesugaringEnabled true，且仍不保证所有方法可用

如果必须读旧代码里的 DateTime 怎么办

不是“怎么配”，而是“怎么最小化影响地过渡”。核心思路：只在需要解析/格式化老数据的地方桥接，其余全部切到 java.time。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 用 DateTime.toInstant().atZone(ZoneId.systemDefault()) 转成 ZonedDateTime，避免直接 new LocalDateTime 忽略时区
• 反向转换：用 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 字符串模式，比依赖本身更难清理。