java - DateTimeFormatter 是否依赖于操作系统？

Question

以下代码:

Locale locale = new java.util.Locale("en", "AU");
DateTimeFormatter fmt = DateTimeFormatter.ofLocalizedDateTime(FormatStyle.MEDIUM).withLocale(locale);
ZonedDateTime zdt = ZonedDateTime.parse("2021-11-19T14:13:12Z");
return fmt.format(zdt);

根据操作系统给出不同的结果:

<表类="s-表"><头>操作系统格式Java<正文> window 2021 年 11 月 19 日下午 2:13:121.8.0_312macOS2021 年 11 月 19 日下午 2:13:121.8.0_312Linux/Ubuntu19/11/2021 下午 2:13:121.8.0_292

这是预期的吗？我的单元测试在不同的上下文中失败，这对我来说似乎很意外

Answer 1

Java 8:对操作系统没有预期的依赖性

自 Java 的早期版本以来，Java 运行时引擎就内置了语言环境数据。来自 Unicode Common Locale Data Repository (CLDR) 的 Java 8 数据也包含在 Java 中，但仍然首选默认的 Java 自己的数据。

使用格式化程序格式化日期和时间的结果预计取决于三个或四个因素:

1. 关于语言环境。
2. 关于区域设置数据的提供者。 Java 最多可以从四个来源获取其区域设置数据:JRE 自己的数据、CLDR、已安装的服务提供商(可以说是你自己)和主机操作系统。使用哪些以及优先级由 java.locale.providers 控制系统属性。
3. 关于来自所选供应商的区域设置数据的版本。
4. 如果是 HOST显然在操作系统上的语言环境数据提供程序。

在 Java 8 中，默认使用 JRE 自己的语言环境数据作为第一优先级，其次是任何配置的服务提供者。无论如何都不是主机操作系统。所以不设置系统属性 java.locale.providers相当于设置为JRE,SPI .这反过来又不会对操作系统产生任何依赖性。

在 Java 9 中，默认值被更改为等同于 CLDR,COMPAT其中 COMPAT是 JRE 的新名称.这反过来仍然不会对操作系统产生任何依赖性。

为什么您观察到不同的结果？

假设你依赖默认的区域设置数据提供者JRE和SPI，并且你没有添加自己的服务提供者(SPI)，那么你的不同结果肯定是由不同版本的Java的区域设置数据造成的。显然他们将语言环境数据从 Java 1.8.0_292 更新到 1.8.0_312。

运行 1.8.0_312 的 Windows 和 Mac 之间的细微差别，Nov 之后的点， 然后？虽然我原以为他们会为不同的操作系统提供相同版本的语言环境数据和 Java 安装程序，但我能想到的解释是在这种情况下他们可能没有。

更多观察结果

我也运行了一些你的代码。下表包括您和我的观察结果。在所有运行中，我都设置了 java.locale.providers至 JRE,SPI在 Java 9 及更高版本上获得 Java 8 行为。

<表类="s-表"><头>Java格式操作系统测试人员<正文>1.8.0_12119/11/2021 下午 2:13:12MacOS我1.8.0_27119/11/2021 下午 2:13:12 window 我1.8.0_29219/11/2021 下午 2:13:12Ubuntu你1.8.0_3122021 年 11 月 19 日下午 2:13:12 window 你1.8.0_3122021 年 11 月 19 日下午 2:13:12MacOS你9.0.42021 年 11 月 19 日下午 2:13:12MacOS我15.0.119/11/2021 下午 2:13:12 window 我

最后的结果很有趣，带点的结果也是如此。

链接

• LocaleServiceProvider 的文档
• Internationalization Enhancements in JDK 9 — CLDR Locale Data Enabled by Default