时间 API 对比 - JavaScript、Python 和 Java 日期库

JavaScript Temporal - 修正 Date 的历史错误

JavaScript 的 Date 对象从 1995 年设计之初就带有诸多问题:月份从零开始(0 = 一月)、Date 是可变对象、时区处理能力薄弱、解析行为在不同浏览器间不一致。Temporal API(TC39 Stage 3)是一次彻底的重新设计,从根本层面解决了这些问题。

Temporal 的核心特征是为不同用途提供多种类型:Temporal.Instant(UTC 绝对时间)、Temporal.ZonedDateTime(带时区的日期时间)、Temporal.PlainDateTime(不带时区的日期时间)、Temporal.PlainDate(仅日期)、Temporal.PlainTime(仅时间)。时区信息的有无在类型层面得到强制,而不是隐含在开发者的心智模型中。

Python datetime + zoneinfo - 标准库的演进

Python 的 datetime 模块区分 naive(无时区信息)和 aware(有时区信息)两类 datetime。Python 3.9 新增了 zoneinfo 模块,提供对 IANA 时区数据库的标准库访问,终结了长期以来对第三方库 pytz 的依赖。

Python datetime 的常见陷阱是混用 naive 和 aware 值。对 naive datetime 进行时区转换会抛出 TypeError,但比较运算符有时会静默地允许混用,导致隐蔽的 bug。推荐的模式是在内部始终使用 aware UTC 时间,仅在显示时转换为本地时间,这与数据库持久化的规则完全一致。

Java java.time - JSR 310 的成熟设计

Java 8 的 java.time 包(JSR 310)由 Joda-Time 作者 Stephen Colebourne 主导设计,是主流语言中最成熟的时间 API。其设计原则 - 不可变性、线程安全、类型的清晰分离(LocalDateTime、ZonedDateTime、Instant、Duration、Period)- 在整个 API 中得到一贯的贯彻。

一个突出的设计选择是明确区分 Duration(基于时间的量,以秒和纳秒为单位)和 Period(基于日期的量,以年、月、日为单位)。“一个月后”根据日历不同可能是 28 到 31 天,因此它与固定秒数有本质区别。在类型层面强制这种区分可以防止一整类运算错误。

跨语言的常见陷阱

跨语言的一个常见陷阱是将纯日期值提升为日期时间时的歧义。将“2026-05-15”转换为 DateTime 时可能以 UTC 午夜或本地午夜为基准,在某些时区中结果会相差一个日历日。如果没有明确指定,你无法判断库选择了哪种方式。

另一个共同问题是宽松的字符串解析。“2026-5-15”、“2026/05/15”、“May 15, 2026”、“15.05.2026”都表示同一日期。使用严格解析(不精确匹配指定格式时直接失败)并避免宽松解析(自动猜测)对于处理国际化输入的系统来说是不可商量的。

库的选型与迁移

对于新项目,使用各语言最现代的标准 API:JavaScript 使用 Temporal(在原生支持到来之前通过 polyfill),Python 使用 datetime + zoneinfo,Java 使用 java.time。仍在使用 Moment.js 或 pytz 的现有项目适合分阶段迁移:新代码使用现代 API,遗留代码在因其他原因修改时伺机转换。

第三方库(Luxon、date-fns、Arrow、Pendulum)能有效填补标准 API 的空白,但会增加依赖和维护负担。避免为标准库已能处理的任务引入它们,将它们保留给真正复杂的需求,如丰富的相对时间格式化或不常见的循环模式运算。依赖越少,当标准进一步演进时下一次迁移就越容易。