生产环境兼容Android API 23时是否适合继续使用Joda库

在需要持续兼容Android API level 23的生产环境中，继续使用Joda是完全合理可行的选择，完全没必要为了跟风业界推荐强行迁移。

• Java 8原生日期API（java.time包）在Android上的兼容成本并不低：Android对java.time的完整原生支持从API 26才开始，API 23既没有原生实现，就算开启核心库脱糖也没法覆盖全部接口能力。如果硬要在这个版本线上用java.time，得额外引入第三方适配库，还要自己填一堆不同厂商ROM的兼容坑，维护成本比继续用Joda高得多。
• Joda的稳定性经过了足够久的生产验证：作为Java生态里最老牌的日期库之一，Joda本身就是Java 8java.timeAPI的设计参考，接口逻辑经过十几年全行业的线上检验，稳定性极强，根本不存在“过时就不能用”的问题。只要你当前用的版本没有会影响你业务逻辑的已知bug，跑线上完全不会有可靠性问题。
• 存量项目迁移的投入产出比极低：如果你的项目已经全量接入Joda，那些涉及日期计算的边界逻辑——比如时区转换、闰年判断、跨天/跨月结算这类最容易出线上故障的逻辑——都已经经过了业务验证。为了“用新API”的名义强行重构，要改遍全项目所有日期相关的调用，还要重新做一轮全场景的边界测试，花的人力、担的故障风险，比用新API带来的那点好处大太多了。

• 要明确：Joda目前处于功能维护模式不等于不能用。官方只是不会再加新特性了，关键的bug、安全问题依然会持续修复，对存量项目来说完全够用。
• 如果是项目里新写的独立模块，不需要复用老的日期处理逻辑，可以考虑用适配低版本Android的java.time适配方案，不用强行绑Joda，但绝对没必要为了统一技术栈去重构已经跑稳定的老代码。
• 继续用Joda的话，记得把依赖版本固定在你已经验证过的稳定版，不要随便跨大版本升级，同时在应用启动的时候统一配置好默认时区，规避部分小众ROM上的时区解析异常问题就行。

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